Remote monitoring of analyte measurements

ABSTRACT

Methods and apparatus, including computer program products, are provided for remote monitoring. In some example implementations, there is provided a method. The method may include receiving, at a remote monitor, a notification message representative of an event detected, by a server, from analyte sensor data obtained from a receiver monitoring an analyte state of a host; presenting, at the remote monitor, the notification message to activate the remote monitor, wherein the remote monitor is configured by the server to receive the notification message to augment the receiver monitoring of the analyte state of the host; accessing, by the remote monitor, the server, in response to the presenting of the notification message; and receiving, in response to the accessing, information including at least the analyte sensor data. Related systems, methods, and articles of manufacture are also disclosed.

INCORPORATION BY REFERENCE TO RELATED APPLICATIONS

Any and all priority claims identified in the Application Data Sheet, orany correction thereto, are hereby incorporated by reference under 37CFR 1.57. This application is a continuation of U.S. application Ser.No. 15/632,181, filed Jun. 23, 2017, which is a continuation of U.S.application Ser. No. 14/142,608, filed Dec. 27, 2013, now U.S. Pat. No.9,730,621, which is a continuation of U.S. application Ser. No.14/142,365, filed Dec. 27, 2013, now U.S. Pat. No. 9,730,620, which is acontinuation-in-part of U.S. application Ser. No. 13/843,382, filed Mar.15, 2013, now U.S. Pat. No. 9,585,563, which is a continuation of U.S.application Ser. No. 13/842,679, filed Mar. 15, 2013, now U.S. Pat. No.9,801,541, which claims the benefit of U.S. Provisional Application No.61/747,717, filed Dec. 31, 2012. Each of the aforementioned applicationsis incorporated by reference herein in its entirety, and each is herebyexpressly made a part of this specification.

FIELD

The present disclosure generally relates to remote monitoring.

BACKGROUND

Diabetes mellitus is a disorder in which the pancreas cannot createsufficient insulin, such as in the case of Type I diabetes and/or inwhich insulin is not effective, such as Type 2 diabetes. In a diabeticstate, a victim suffers from high blood sugar, which causes an array ofphysiological derangements, such as kidney failure, skin ulcers, orbleeding into the vitreous of the eye, associated with the deteriorationof small blood vessels. A hypoglycemic reaction, such as low bloodsugar, may be induced by an inadvertent overdose of insulin, or after anormal dose of insulin or glucose-lowering agent accompanied byextraordinary exercise or insufficient food intake.

A diabetic person may carry a self-monitoring blood glucose (SMBG)monitor, which typically requires uncomfortable finger pricking methods.Due to the lack of comfort and convenience, a diabetic typicallymeasures his or her glucose level only two to four times per day.Unfortunately, these time intervals are spread so far apart that thediabetic will likely find out too late, sometimes incurring dangerousside effects, of a hyperglycemic or hypoglycemic condition. In fact, itis not only unlikely that a diabetic will take a timely SMBG value, butadditionally the diabetic will not know if his blood glucose value ishigher or lower based on conventional methods.

Consequently, a variety of non-invasive, transdermal (e.g.,transcutaneous) and/or implantable electrochemical sensors are beingdeveloped for continuously detecting and/or quantifying blood glucosevalues. These as well as other types of devices generally transmit rawor minimally processed data for subsequent analysis at a remote device,which can include a display, to allow presentation of information to auser hosting the sensor.

SUMMARY

Methods, systems and apparatus, including computer program products, areprovided for remote monitoring of analyte data. In some exampleimplementations, there is provided a method. The method may includereceiving, at a remote monitor, a notification message representative ofan event detected, by a server, from analyte sensor data obtained from areceiver monitoring an analyte state of a host; presenting, at theremote monitor, the notification message to activate the remote monitor,wherein the remote monitor is configured by the server to receive thenotification message to augment the receiver monitoring of the analytestate of the host; accessing, by the remote monitor, the server, inresponse to the presenting of the notification message; and receiving,in response to the accessing, information including at least the analytesensor data.

In some example implementations, the above-noted aspects may furtherinclude additional features described herein including one or more ofthe following. The notification message may be received from at least afirst wireless connection between the remote monitor and a notificationservice coupled to the server, wherein the additional information may bereceived from at least a second wireless connection between the remotemonitor and the server. The first wireless connection may comprise apersistent, encrypted connection configured to carry a short messagepushed by the notification service to a notification message center atthe remote monitor, and wherein the second wireless connection maycomprise a momentary, encrypted connection established, in response theaccessing, to provide the additional information comprising at leastadditional analyte sensor data. The presenting may further compriseinhibiting access to one or more applications at the remote monitoruntil an action at the remote monitor is detected to indicate receipt ofthe notification message, wherein the remote monitor further maycomprise a monitoring application. The notification message may bepresented as a momentary message on a display at the remote monitor,without the inhibiting access. The at least one of the remote monitorand the receiver may comprise one or more of a mobile station, awireless terminal, a tablet, a smart phone, a multi-mode wirelessdevice, and a computer. The server may comprise at least one processorconfigured to receive analyte sensor data from the receiver, process theanalyte sensor data to detect the event, and forward, when the event isdetected, the notification message to the remote monitor based on one ormore rules mapping the event to the remote monitor designated to receivethe notification message for the detected event. The event may bedetected based on a first set of rules at the server, wherein the firstset of rules used to generate the notification message may be differentfrom a second set of rules used to detect alerts sent to the receivercoupled to a sensor system at the host. The receiver may include, orcouple to, a gateway interfacing a wireless connection to a public landmobile network and the server. A plurality of remote monitors may beconfigured, wherein at least one of the plurality of remote monitors maybe designated as a primary monitor, and at least one of the plurality ofremote monitors may be designated as a secondary monitor. The remotemonitor may configure at least one rule representative of a triggercausing an alert to be sent by the server to the receiver. The remotemonitor may configure one or more invitations sent to one or moredevices to invite the one or more devices to monitor the receiver. Theserver may send a message acknowledging a receipt of the notificationmessage. The notification message may include at least one of anindication of a need to calibrate a sensor and an acknowledgementmessage indicating at least one of an action or an acknowledgement sentby the receiver in response to an alarm sent to the receiver. Theactivation of the remote monitor may comprise opening the monitoringapplication. A connection may be established between the remote monitorand the server to enable the receiving of the information including theanalyte sensor data. The server may register at least one of the remotemonitor, the receiver, an analyte sensor coupled to the receiver, andthe registration may include a code provided by a health care provider.The method may be implemented on an apparatus comprising at least oneprocessor and at least one memory including code, which when executed bythe at least one processor causes the apparatus to provide the method. Acomputer-readable storage medium may include code which when executed byat least one processor causes the method.

In some exemplary implementations there is provided a method thatincludes receiving, at a remote monitor, an invitation to access asecure server and data associated with a receiver monitoring an analytestate of a host; and modifying, by the remote monitor, a rule definingan alert representative of an event associated with the analyte state ofthe host, wherein the alert, when triggered, causes a message to be sentto the remote monitor to notify the remote monitor of the event.

In some example implementations, the above-noted aspects may furtherinclude additional features described herein including one or more ofthe following. The modifying the rule may comprise varying a firstthreshold associated with a low level of glucose at the host, varying asecond threshold associated with a high level of glucose at the host,varying a delay between when an associated alert is triggered by areceiver and a notification message is sent to the remote monitor,and/or varying a time value when a reminder notification is sent to theremote monitor. The method may be implemented on an apparatus comprisingat least one processor and at least one memory including code, whichwhen executed by the at least one processor causes the apparatus toprovide the method. A computer-readable storage medium may include codewhich when executed by at least one processor causes the method. In someimplementations, there is provided a method or system, includingcomputer program products, for wireless communication between computingdevices of a continuous glucose monitoring system. The method maycomprise: receiving, using a gateway device, a heartbeat message from areceiver, the heartbeat message triggering connection logic; requestinga latest analyte concentration value and a receiver time from thereceiver; identifying sensor data gaps of analyte concentration datastored at a remote server; requesting, using the gateway, one or moretimeframes of sensor data from the receiver based on the identified datagaps; and providing the sensor data to the server.

The above-noted implementations may further comprise: requestingmanufacturing data from the receiver, wherein the manufacturing datacomprises a unique identifier associated with the receiver; and checkinga status of the receiver based on the manufacturing data, the checkingcomprising sending a message to the remote server and subsequentlyreceiving an indication of whether the status of the receiver is validor invalid from the remote server, wherein the requesting of the latestanalyte value only occurs if the status of the receiver is valid.

The above-noted implementations may further comprise: requesting auniversal time from the server; and calculating a drift in time based ona difference between the receiver time and the universal time, whereinidentifying the sensor data gaps is based on the drift in time. Further,the above-noted aspects may store the drift in memory of the gatewaydevice.

In some implementations, there is provided a method or system, includingcomputer program products, for wireless communication between computingdevices of a continuous glucose monitoring system, comprising:iteratively receiving a heartbeat message transmitted by a receiver;determining if it is time to request data from the receiver responsiveto each received heartbeat message based on whether more than apredetermined amount of time has elapsed based on a heartbeat counter;and obtaining glucose concentration data from the receiver if it isdetermined that it is time to request sensor data from the receiver.

In the above-noted implementations, the obtaining may further compriserequesting a latest glucose value data and a current system time fromthe receiver, and uploading the requested latest glucose value data to aremote server upon receipt of the requested latest glucose value data.

The above-noted implementations may further comprise determining if thelatest glucose value data is valid; and if determined to be valid,storing the requested latest glucose value data locally and resettingthe heartbeat counter.

The above-noted implementations may further comprise resetting theheartbeat counter without storing the latest glucose value locally ifthe data is determined not to be valid.

The above-noted implementations may further comprise transmitting aCheckSession call to the server to keep a current login session active.

In some implementations, there is provided a method or system, includingcomputer program products, for monitoring a host's glucose levelsmeasured using a continuous glucose monitoring system, comprising:receiving a voice input using a mobile computing device; processing thevoice input to determine one or more commands; and implementing the oneor more commands.

The above noted implementations may also include one or more of thefollowing: wherein the one or more commands include outputting aparticular glucose value; wherein the particular glucose value is thecurrent glucose value; wherein the voice input comprises an indicationof a past time frame and the particular glucose value is a glucose valuecorresponding to the past time frame; wherein the outputting comprisesaudibly providing the particular glucose value using the mobilecomputing device and displaying the current glucose value on a displayof the mobile computing device; wherein outputting further comprisestriggering display of a glucose trend graph of the host's measuredglucose concentration over time; wherein the one or more commands iscalibrating the glucose monitoring system using a calibration valueindicated in the voice input confirming the calibration value based on adifference between the calibration value and a current glucose valueassociated with the host wherein the voice input comprises aninstruction to modify alert settings of the continuous glucosemonitoring system, and wherein the one or more commands comprisemodifying one or more alert settings in accordance with theinstructions; wherein modifying the alert settings comprises one or moreof modifying and alarm profile, changing an alarm threshold, and turningoff or on a particular alarm; wherein the voice input comprises anacknowledgement of an alert previously triggered by the remotemonitoring system, and wherein the one or more commands comprise turningoff the triggered alert; wherein the voice input comprises an indicationof one of a plurality of host's a user is remotely monitoring using theglucose monitoring system; wherein the one or more commands includesselecting the host and wherein the outputting comprises audiblyproviding and/or displaying a state of the host; and wherein the stateof the host comprises one or more of a current glucose value of thehost, a rate of change of glucose concentration of the host, and alocation of the host.

In some implementations, there is provided a method or system, includingcomputer program products, for monitoring a host's glucose levelsmeasured using a continuous glucose monitoring system, comprising:enabling a voice feedback setting of the continuous glucose monitoringsystem using a mobile computing device; receiving continuous glucosesensor data measured by the continuous glucose monitoring system;processing the continuous glucose sensor data; and outputting voicefeedback using the mobile computing device in accordance with the voicefeedback setting and the processed continuous glucose sensor data.

The above noted implementations may also include one or more of thefollowing: wherein enabling the voice feedback setting includesselecting at least one of a plurality of alert parameters; and whereinthe plurality of alert parameters comprises a time interval forautomatically providing voice feedback, a glucose threshold and a rateof change threshold.

It is to be understood that both the foregoing general description andthe following detailed description are example and explanatory only andare not restrictive. Further features and/or variations may be providedin addition to those set forth herein. For example, the implementationsdescribed herein may be directed to various combinations andsubcombinations of the disclosed features and/or combinations andsubcombinations of several further features disclosed below in thedetailed description.

DESCRIPTION OF THE DRAWINGS

In the drawings,

FIG. 1 depicts a high-level system architecture of a remote monitoringsystem in accordance with some exemplary implementations;

FIGS. 2A-2C illustrate different system architectures of the remotemonitoring system of FIG. 1 in accordance with some exemplaryimplementations;

FIG. 3 depicts an example process for notifying a remote monitor of anevent in accordance with some example implementations;

FIGS. 4A and 4B depict examples of notification messages 170 and 172,respectively, in accordance with some implementations;

FIG. 5 depicts an example of a sensor electronics module in accordancewith some example implementations;

FIG. 6 is a block diagram of an implementation of a gateway inaccordance with some implementations;

FIGS. 7A and 7B depict an example of a docking station in accordancewith some implementations;

FIG. 8 depicts an implementation of a gateway or docking station inaccordance with some implementations;

FIG. 9 illustrates an exemplary display page to facilitate entry of theserial number of a receiver or other unique identifier in accordancewith some implementations;

FIG. 10 is a flow chart depicting a process for setting up hostmonitoring system in accordance with some implementations;

FIGS. 11A and 11B are exemplary views of a status page in accordancewith some implementations;

FIG. 12 depicts an example invitation page presented at a remote monitorin the form of an email message in accordance with some implementations;

FIG. 13 depicts an example alert setting page that may be presented on adisplay of the host computing device;

FIG. 14 illustrates an overview page of remote monitors displayed by ahost monitoring device in accordance with some implementations;

FIG. 15 is an exemplary remote monitor settings display page displayedby a host monitoring device in accordance with some implementations;

FIG. 16 is a flowchart of an exemplary remote monitor set up process inaccordance with some implementations;

FIG. 17 is an implantation of a settings page that can allow the remotemonitor to configure remote monitoring settings of a host in someimplementations;

FIGS. 18A and 18B are two different implementations of a dashboard pagedisplayed by a remote monitor in accordance with some implementations;and

FIG. 19 is an exemplary page that provides a trend graph of a host'smonitored analyte concentration in accordance with some implementations;

FIG. 20 is a diagram of wireless connection processing in accordancewith some implementations; and

FIG. 21 is a diagram of steady state wireless connection processing inaccordance with some implementations.

DETAILED DESCRIPTION

Implementations described herein can include a system for one or morecaretakers (e.g., a parent, spouse or healthcare practitioner) toremotely monitor health characteristics of one or more hosts. The healthcharacteristics can include an analyte concentration of a host, such asglucose, or a bodily function, such as heart rate, blood pressure, ortemperature, and the like. In addition, other characteristics of a hostcan be monitored to facilitate care of a host, such as a geographiclocation of the host, state of a host (e.g., exercising, sleeping, orworking) and the like. The health characteristics and othercharacteristics can be gathered using a host monitoring system thatincorporates a computing device, such as a smart phone, and one or moresensors, such a continuous glucose sensor, heart-rate monitor, GPSdevice, etc. Additionally, a host can manually input information intothe computing device, such as meal information, medicationadministration times and amounts, and the like. The information gatheredby the host monitoring system can then be transmitted to one or moreremote monitors used by caretakers. The caretaker(s) can then receiveinformation about the host's health condition using a remote monitoringsystem. In some implementations, a host monitoring system can transmitinformation directly to the one or more remote monitors and/or the hostmonitoring system transmits information first to a remote server, whichthen transmits information to the host monitor.

For purposes of illustration only, the following example is anon-limiting exemplary environment in which implementations of remotemonitoring systems described herein can be used.

In this exemplary environment, a host having diabetes is monitored byseveral different caretakers. The host has a continuous glucosemonitoring system, such as the DexCom G4® Platinum continuous glucosemonitoring system, commercially available from DexCom, Inc., whichprovides measurements of the host's glucose levels on a display device,such as the DexCom G4® Platinum Receiver, also commercially availablefrom DexCom, Inc.

Further, in this exemplary environment, the display device can be incommunication with a gateway device, such as via wired communication orwireless communication. The gateway device gathers information,including real-time or near-real-time glucose concentration values, fromthe display device and transmits the information to a secure server. Thegateway device can include a smartphone, such as an iPhone® 4S or iPhone5, each commercially available from Apple, Inc., and a host monitoringsoftware application that comprises instructions configured to cause thesmartphone to function as the gateway. The host monitoring softwareapplication can be in the form of a so-called “App” downloaded from theApple App Store℠ operated by Apple, Inc. The gateway can transmitinformation gathered from the continuous glucose monitoring systemwirelessly to the secure server over a cellular network, Wi-Fi network,and the like.

The remote server can store and monitor the information received fromthe remote monitoring system. The monitoring can include comparingglucose values of the host (generated by the continuous glucosemonitoring system and transmitted to the server via the gateway) topredetermined thresholds and initiating an action if a threshold isexceeded. For example, the server can compare a current glucose value(e.g., the most recently viewed glucose value) with a predeterminedglucose threshold and initiate a notification, such as a text messageover a cellular network, to a remote monitoring system if the glucosevalue exceeds the threshold. The server can also provide historical andcurrent glucose values to the remote monitoring system on demand.

As discussed above, the remote monitor can be used by a caretaker tomonitor health characteristics of a host, which in this exemplaryenvironment is a glucose concentration level of the host. Similar to thehost monitoring system, the remote monitoring system can be asmartphone, such as an iPhone 4S or iPhone 5, and a remote monitoringsoftware application that comprises instructions configured to cause thesmartphone to function as the remote monitoring system. The remotemonitoring software application can be in the form of a so-called “App”downloaded from the Apple App Store operated by Apple, Inc. The remotemonitoring system can receive notifications from the server when athreshold is exceeded, notifying the caretaker using the remotemonitoring system of the condition of the host. The remote monitoringsystem can also be used to view historical information about themonitored glucose levels of the host and modify notification rules, suchas the threshold levels that trigger notifications.

The following provides more detail of specific implementations, whichmay or may not include features noted in the above-discussed exemplaryenvironment.

FIG. 1 depicts a high-level system architecture of an implementation ofremote monitoring system 100. Here, remote monitoring system 100includes a plurality of host monitoring systems 198A-198N connected to aplurality of remote monitors 114A-114M via network 118. Each hostmonitoring system 198 may be one or more health monitoring devices thatgather health-related data associated with a host and transmit thehealth-related data via network 108. Exemplary implementations of healthmonitoring systems 198A-198N are described in more detail elsewhere inthis disclosure, but in some implementations can include one or moresensors and computing devices operably coupled to the sensors to gather,process and transmit the health-related data. Network 108 can includeany communication medium, such as wired and wireless networks includingcellular networks, local area networks, wide area networks, Wi-Finetworks, the internet, and the like. Network 108 can also include oneor more servers 110 to process the health-related data received from andtransmit notifications and data to one or more remote monitors 114A-114Meither automatically or in response to a request from the remotemonitors.

Each remote monitor 114A-114M can be associated with an individual orentity that is monitoring the health of one or more of hosts using hostmonitoring systems 198A-198N. Each remote monitor 114 can be associatedwith a caretaker, such as parent, spouse, doctor, nurse, hospital andthe like. The remote monitor 114 can include a computing device thatreceives notifications from network 108 and requests additionalinformation, such as historical health-related data generated by one ormore host monitoring systems 198A-198N.

Remote monitoring system 100 of FIG. 1 can also include workstation 22.Workstation 22 may be a computing device, such as a personal computer,that has access to remote monitoring system 100 for configuring settingsof system 100 and/or viewing information associated with one or morehost monitoring systems 198, such as reports generated by remotemonitoring system based on a host's health-related data.

Using remote monitoring system 100 of FIG. 1, one or more remotemonitors 114A-11M can monitor one or more host monitoring systems198A-198N. As an example, host monitoring system 198A can be monitoredby remote monitors 114A and 114B, and at the same time, remote monitor114A can monitor host monitoring system 198B as well. Variouspermissions and invitations can be used to limit which remote monitors114A-114M can monitor host monitoring systems 198A-118N, as described inmore detail later in this disclosure.

In one non-limiting example of remote monitoring system 100, each hostmonitoring system 198A-198N comprises a smart device, such as an iPhonemobile phone or iPod touch® mobile device from Apple, Inc., and,likewise, each remote monitor 114A-114M has a smart device, such as aniPhone or iPod touch. Each host smart device has a host softwareapplication downloaded from a server of network 108, the applicationconfiguring the smart device to perform any of the functions by hostmonitoring system 198 described herein, including gathering andtransmitting health-related data used in remote monitoring system 100.The host software application can be an application downloaded using theApp Store service hosted by Apple, Inc. Similarly, each remote monitor114A-114M has a remote monitoring application downloaded from a serverof network 108, the remote monitoring application configuring to performany of the remote monitoring functions described herein, includingreceiving notifications and requesting health-related data of a host.The remote monitoring application can also be a software applicationdownloaded using the App Store service hosted by Apple, Inc.

FIG. 2A depicts an example of system 100 for monitoring health-relatedinformation of host 199, in accordance with some exampleimplementations. Here, the remote system 100 includes a continuousanalyte monitoring system 8 including a sensor electronics module 12 anda continuous analyte sensor 10. The system 100 may also include otherdevices and/or sensors, such as medicament delivery pump 2 (e.g., aninsulin or glucagon pump), a glucose meter 4 (e.g., a blood finger stickmeter), and any other device and/or sensor. The continuous analytesensor 10 may be physically connected to sensor electronics module 12and may be integral with (e.g., non-releasably attached to) orreleasably attachable to the continuous analyte sensor 10.

The sensor electronics module 12, medicament delivery pump 2, a glucosemeter 4, and/or other devices/sensors may couple via a wired or wirelesslinks to one or more devices, such as a receiver 102. The receiver 102may include a display 122 to enable the host 199 to present informationfrom and/or control continuous analyte sensor 10, delivery pump 2,glucose meter 4, and/or other devices/sensors.

The implementation of system 100 illustrated in FIG. 2A provides via agateway 104, networks 108A-C, a secure server 110, and a notificationservice 112, notification messages to one or more remote monitors114A-114M, such as remote monitor 114A. Each remote monitor 114 may beconfigured at system 100 to provide a separate mechanism for monitoringthe activity associated with host 199 including receiver 102, continuousanalyte sensor 10, delivery pump 2, glucose meter 4, and/or any othersensor associated with host 199.

To illustrate by way of an example, host 199 may access receiver 102 toview data from, or control aspects of, continuous analyte sensor 10,delivery pump 2, and/or glucose meter 4. However, another entity, suchas a parent, a care giver, a health care professional, a school nurse,and the like, may have remote monitor 114 receive notification messagesrepresentative of certain events determined based on sensor data fromreceiver 102, continuous analyte sensor 10, delivery pump 2, and/orglucose meter 4, and view historical and substantially real-time sensordata. For example, an event may comprise one or more of the following: ameasured analyte sensor value above or below a predetermined threshold,a rate of change or a level of glucose measurements above apredetermined threshold, a predicted glucose value approaching (orpredicted to approach) a predetermined threshold, a host 199 notresponding to a prompt, a message, or an alert displayed at receiver102, and/or any other event detected by secure server 110 and/orreceiver 102. In the example of FIG. 2A, the remote monitor 114 depictsa notification message 132 indicating low glucose level of host 199. Assuch, an entity having remote monitor 114 may assist host 199 byproviding an additional layer of monitoring and oversight of host 199,as well as receiver 102, continuous analyte sensor 10, delivery pump 2,glucose meter 4, and the like.

In some example implementations, the remote monitor 114 may include aprocessor, a non-transitory computer-readable storage medium (e.g.,memory, storage, and the like), a radio access mechanism (e.g., a modemand the like), and/or a user interface. The computer readable medium mayinclude code which when executed by a processor provides one or moreapplications, operating systems, and the like. For example, anapplication may be configured as a remote monitoring applicationconfigured to monitor and/or control one or more of the receivers 102,the continuous analyte sensor 10, the delivery pump 2, the glucose meter4, and the like. In some implementations, the remote monitor 114 is aniPhone mobile phone from Apple, Inc. and the application is anapplication downloaded over the Internet using the App Store serviceoperated by Apple, Inc.

In some example implementations, the remote monitor 114 may comprise oneor more of the following: a mobile station, a wireless terminal, atablet, a smart phone, or the like. For example, the remote monitor 114may be implemented as a wireless handheld device, a wireless plug-inaccessory, or the like. Moreover, the remote monitor 114 may beimplemented as multi-mode device configured to operate using a pluralityof radio access technologies, such as Long Term Evolution (LTE),wireless local area network (WLAN) technology, such as 802.11 Wi-Fi andthe like, Bluetooth, Bluetooth low energy (BT-LE), near fieldcommunications (NFC), and any other radio access technologies. Moreover,the remote monitor 114 may be configured to establish connections toaccess points in network 108A, such as cellular base stations, Wi-Fiaccess points, and the like, using at least one of the plurality of theradio access technologies. It is also understood that while some of theexamples herein refer to the remote monitor 114 as a mobile, wirelesscomputing device for purposes of explanation wherein, the remote monitormay be implemented as a stationary device, such as a personal computerand the like.

In some example implementations, alert rules of the receiver 102 may bedifferent from the remote monitor 114. For example, a different set ofrules may define when an alert is sent and/or triggered by to thereceiver 102, when compared to the set of rules used to trigger anotification to the remote monitor 114. Moreover, although the receiver102 may trigger alerts on its own (e.g. applying thresholds to sensordata received from sensor system 8), receive alerts from sensor system 8or receive alerts directly from the secure server 110, the remotemonitor 114 may be configured to receive messages, such as shortmessages, text messages, and the like, from a notification service 112,and these messages can serve to activate the remote monitor 114, such asactivating the remote monitor application of the remote monitor. Forexample, the remote monitor 114 may close the remote monitor applicationsession (as well as close network connection 109 to secure server 110),when the remote monitor application is not actively being used toconserve power at the remote monitor. When this is the case, thenotification service 112 may send a message over network connection 111to activate of the remote monitor 114 and/or a remote monitorapplication (and this activation may be automatic or under the controlof a user of remote monitor 114).

Although some of the examples described herein refer to secure server110 as an intermediary node between the receiver 102 and the remotemonitor 114, in some example implementations, the secure server 110 maybe by-passed. For example, the gateway 104 may communicate directly withthe remote monitor 114, and vice-versa. In addition, the gateway 104 andreceiver 102 may receive notification messages to activate anapplication at the receiver 102 or gateway 104 to allow the host to bealerted.

FIG. 3 depicts an example process 197 for notifying a remote monitor 114of an event associated with receiver 102, continuous analyte sensor 10,delivery pump 2, glucose meter 4, and/or host 199, in accordance withsome example implementations. The description of FIG. 3 also refers toFIG. 2A.

In some example implementations, the secure server 110 may registerand/or configure one or more of the receiver 102, the continuous analytesensor 10, the delivery pump 2, the glucose meter 4, and the host 199before process 197 is initiated, although registration and/orconfiguration may occur at other times as well. The registration processmay be performed to register the receiver 102, the continuous analytesensor 10, the delivery pump 2, the glucose meter 4, the remote monitor114, and/or the host 199 with the secure server 110. Moreover, theconfiguration process may be performed to configure system 100 includingthe identities of the one or more remote monitors used to monitorreceiver 102, configure one or more rules used to trigger notificationmessages to the remote monitors, configure one or more rules designatingprimary and secondary remote monitors, configure one or more rulesestablishing schedules for the primary and secondary monitors, configureone or more rules defining an escalation sequence representative of whento elevate an event to a primary monitor or a secondary monitor, and thelike.

At 180, receiver 102 may send sensor data, such as analyte data fromsensor system 8 and the like, to gateway 104, which then forwards thesensor data at 182 to secure server 110. For example, receiver 102 maycouple to gateway 104 via a wired or wireless connection, and gateway104 may couple to secure server 110 via network 108A. The gateway 104may be configured to pull current and/or historical data from thereceiver 102 on its own or in response to a request from secure server110.

At 186, the secure server 110 may determine whether one or more of theremote monitors 114A-114M, such as remote monitor 114A, should be sent anotification message regarding an event. The secure server 110 maydetermine whether to send a notification message to a remote monitor 114based on received sensor data (as well as any other data available atthe secure server), which triggers an event (or satisfies a rule) at thesecure server. For example, secure server 110 may receive the sensordata at 182 and then process the received sensor data alone or alongwith other data (e.g., historical data, data from other sources ofpatient information, and the like) to determine whether to send thenotification message alerting the remote monitor 114 of the event. Thesecure server 110 may also receive information from other systems, suchas a heath management system or a health care provider's system, andthis information may be used to trigger notification messages to theremote monitor. In addition, the secure server 110 may send notificationmessages to confirm whether the remote monitor is still activelymonitoring the host 199.

To illustrate by way of an example, receiver 102 may receive sensor datafrom host 199 and transmit the sensor data to secure server 110 viagateway 104 and network 108A, and the secure server 110 may process thesensor data and determine a glucose level event by comparing the mostcurrent glucose level data to a predetermined low glucose threshold,although other events described herein may be detected as well. Thesecure server 110 may include one or more rules defining events, such asthe low level of glucose exceeding a threshold and include rulesdefining the identities of the remote monitors receiving a notificationmessage indicating the low level of glucose at the host 199. Forexample, the rule may define that when a low level of glucose isdetected for a certain host, a certain remote monitor should receive anotification message. The notification message may include an indicationof the low level of glucose (e.g., the glucose value), the time of theevent, and other information, such a plot of current and past glucoselevels, host information (e.g., name), and/or any other host relatedinformation.

The one or more rules defining the events may be defined during theconfiguration process by a user, such as host 199, a caregiver, and/orpredefined as default rules (which may be reconfigured by a user or maybe adapted by the system 100 over time to accommodate the host). In someexample implementations, the one or more rules may define a thresholdvalue representative of a severity of the event that should be reportedto the one or more remote monitors, the times of day when a notificationmessage should be sent to each of the remote monitors, the identities(e.g., phone number, Internet Protocol address, email address, and thelike) of the one or more remote monitors, and the like.

Furthermore, the one or more rules may include escalation rules, so thatevents can be handled differently based on severity of event, type ofevent, and/or lack of responsiveness by a designated remote monitor. Forexample, a rule may define that a glucose value below a certain valueshould not be the subject of a notification message to remote monitor114 (although an alert message may be sent to the receiver 102 orgateway 104 to notify the host 199); another rule may define that aglucose value between a range of values should be the subject of anotification message to remote monitor 114; while another rule maydefine sending, when a dangerously low glucose value is detected,notification messages to remote monitor 114A as well as other remotemonitors 114B-M. In some example implementations, the rules used totrigger alerts to host 199 at receiver 102 may be different from therules used to send notification messages to remote monitor 114, althoughone or more of the rules may be the same as well.

Although the previous examples described an event associated with lowglucose levels, other types of events described herein may be defined aswell at the secure server 110 in order to trigger notification messagesto the remote monitor 114 and/or trigger alerts to the receiver 102.

At 187, the secure server 110 may send an alert to the receiver 102and/or gateway 104. The alerts may be triggered based on events whichare the same or different as the rules used to trigger events fornotification messages to the remote monitor 114. Moreover, the secureserver 110 may include a delay between when the alert is sent at 187 andthe notification messages are sent at 188-190. For example, the delaymay allow the receiver 102 to acknowledge or take action before sendingmessages at 188-190, as the receiver may also have a set of rules thatare the same or different than those for the receiver stored on thesecure server. That is, the receiver 102 may trigger an alert based onrules residing within the receiver, and the receiver may receive analarm from the secure server based on a different set of rules stored atsecure server. The delay prior to the secure server 110 sending anotification to the receiver 102 may be varied by the secure serverbased on the severity or type of event, and the delay may be configuredby a user and/or configured programmatically. For example, a first delaymay be used for a first low analyte threshold, but no delay may be usedfor a second, more severe, low glucose threshold.

At 188-190, a notification message may be sent to one or more remotemonitors based on whether one or more rules are triggered at 186. Insome example implementations, the secure server may send a notificationmessage to a push notification service 112, which then pushes anotification to the remote monitor(s). Examples of push notificationservices include the Apple Push Notification Service (APNS) and GoogleCloud Messaging, although any other messaging mechanism including email,short messaging service, tweets, and the like may be used as well. Inthe case of APNS, the remote monitor 114 (or a notification messagecenter therein) may establish an Internet Protocol (IP) connection withthe APNS. This connection may be encrypted, persistent, and/oraccredited, so that the notification service can send notificationmessages to the notification message center even when the remote monitorapplication and/or remote monitor are not actively being used. Forexample, the notification message center may alert the user of theremote monitor 114 that a notification message had arrived for theremote monitor application.

In an implementation utilizing a push notification service, thenotification service 112 may receive a notification message from secureserver 110. The notification message may include a destination address,such as a phone number of the remote monitor 114, an IP address, and thelike, and a payload, such as the contents of the notification message.Returning to the previous example regarding low glucose level, thenotification message may include the phone number of remote monitor 114and a short text message, such as a low glucose level value, time ofmeasurement of the value, and/or an identity of the host. Thenotification message may be limited to 256 bytes, although other sizedmessages may be used as well. In any case, the notification service 112pushes the notification message to remote monitor 114 via a connection,such as an Internet Protocol (IP) connection, between the notificationservice 112 and a notification message center at the remote monitor 114.When the notification message center at the remote monitor 114 receivesthe notification message, the notification message center may displaythe notification message, generate a sound, a vibration, and anotherother indication to a user of the remote monitor 114. And, in someexample implementations, the notification message center or a user ofthe remote monitor may activate the remote monitoring application if theremote monitoring application at the remote monitor 114 is not activelybeing used. The notification service 112 may be used in implementationsin which the remote monitor 114 resides on a device, such as a smartphone and the like, that places the remote monitor 114 or theapplications therein in an idle or an inactive mode to conserve power orreduce signaling to/from the network.

In some example implementations, the push notification service may beby-passed, so that the secure server 110 sends the notification messagedirectly to the remote monitor 114 and/or the remote monitoringapplication therein. This may occur, for example, when the remotemonitoring application is open on the remote monitoring device.

When the notification message is received at 192, the remote monitor 114or a remote monitoring application therein may be activated if in anidle mode or an inactive mode. Once activated (which can beprogrammatically or under the control of a user), the remote monitor 114may attempt to establish a connection to secure server 110. For example,the remote monitoring application may not be actively being used (e.g.,in an idle mode, sleep mode, off, in background mode, and the like). Toactivate the remote monitoring application, the remote monitoringapplication may be activated by, for example, opening the remotemonitoring application by selecting and expanding the remote monitoringapplication, actively using the remote monitoring application byentering a value into, selecting an element of the user interface of theremote monitoring application, and the like. Moreover, the remotemonitor and/or remote monitoring application may be activated by otherways as well. For example, activation may be invoked by movement of theremote monitor detected by a motion sensor and/or turning on, orincreasing the intensity, of the display at the remote monitor.

In response to acknowledgement that the remote monitor 114 has activatedthe remote monitoring application via access message 194, the secureserver 110 may send at 196 additional information to the remote monitor.The content of the additional information sent from the secure server110 to the remote monitor 114 may be automatically determined or may bedefined by a request from remote monitor, which may be a requestincluded in the access message 194 or a subsequent message from theremote monitor. The additional information may include one or more ofthe following: all available sensor data not currently stored in theremote monitor 114, sensor data over a predetermined amount of time,such as the previous 3 or 24 hours of glucose data obtained from thesensor system 100, receiver 102, and/or secure server 110, a plot of theglucose levels over time, a glucose variability value, instructions,motivational messages, status of host, remote monitoring permissionsmodified by the host, and the like.

In some implementations, the secure server 110 automatically sendssensor data from the past three hours to the remote monitor and theremote monitor can request any additional amount of past sensor datashould the remote monitor want to evaluate the host over a longer periodof time. The secure server 110 may query the receiver 102 via gateway104 for additional data in order to respond should the secure server nothave all sensor data specified in a request from the remote monitor 114.

To illustrate further, when the remote monitor 114 receives thenotification message, the notification may cause message 132 to appearon a display screen of the remote monitor 114 as depicted in FIG. 2A.From the message 132, the remote monitoring application may beactivated, either autonomously or under the direction of a user and/ornotification message center. The remote monitoring application may thenaccess at 192 the secure server 110 and programmatically receive anyadditional information associated with the event or other data since thelast connection to secure server 110. For example, once the notificationmessage is acknowledged with an access at 194 or an acknowledgementmessage, secure server 110 may automatically respond with a page havinga trend graph of the current glucose state and information indicatingthe severity of the event (or any other information available at securesensor 110). Although the secure server 100 may instead respond with asubset of the data, in which case, the secure server 110 mayautomatically respond with new data since the last connection to secureserver 110, so that remote monitor can generate a page including thetrend graph showing the last 3 hours' worth of glucose levels. In anycase, the remote monitor may be configured to automatically present,when message 196 is received, the page showing relevant eventinformation, such as a trend graph covering a predetermined time period(e.g., a three hour history of glucose levels) for the host. Anexemplary page that can be automatically presented is illustrated inFIG. 19, which is discussed in more detail elsewhere in this disclosure.

Although FIG. 3 is primarily discussed with respect to remote monitor114 monitoring a single host for ease of understanding, it is understoodthat the remote monitor may be monitoring multiple hosts, as discussedelsewhere herein. As such, secure server 110 may have sensor data andadditional information associated with other hosts. Accordingly, in someimplementations secure server can automatically send over sensor data ofthe other hosts remote monitor is monitoring, along with the sensor datafrom the host that triggered the notification 190 to the remote monitor.In this manner, remote monitor 114 can have an updated set of sensordata and other information associated with each of the hosts remotemonitor is monitoring.

FIGS. 4A and 4B depict examples of notification messages 170 and 172,respectively. In the example of notification message 170, thenotification message 170 may be presented at remote monitor 114 as awindow requiring a user interaction, when the remote monitor 114receives the notification message. For example, the user interaction maycomprise pressing a button on remote monitor 114, touching the screen ofremote monitor over the area associated with a portion of the message170 or activating (e.g., executing, opening, and the like) the remotemonitoring application at remote monitor 114. In some instances, thenotification message 170 may appear when another application at remotemonitor 114 is actively being used. When this is the case, a userinteraction may comprise touching the screen over the area associatedwith a portion of the message 170 to acknowledge receipt of thenotification message 170 before the user is allowed to resume the otherapplication, although the user action may also preempt the otherapplication and make the remote monitoring application the activeapplication being viewed at the remote monitor. Moreover, the decisionof whether to preempt the other application or resume the otherapplication may be predetermined based on the severity level of theevent, so that relatively more severe events preempt the otherapplication, while less severe events do not.

In the example of notification message 172, the notification message 172may be presented at remote monitor 114 as a message that appears in theuser interface as an informational message not requiring intervention onthe part of the user. Furthermore, when notification message 172 appearswhile another application is being used at remote monitor 114,notification message 172 does not require the user to acknowledgenotification message 172, or even activation of the remote monitoringapplication (which may be idle or inactive state at remote monitor 114),resulting thus in the continued use of the other application by theuser.

In some implementations, notifications 107, 172 alert a user that athreshold has been exceeded, but does not provide an analyte value. Inthis way, the user could be required to open up the monitoringapplication to view the monitored host's analyte concentrationinformation. A reason for omitting analyte value information is that thenotification may not be a current value due to time lag or other systemfaults. Further, to this end, remote monitoring system 100 can beconfigured so an analyte concentration value is not displayed even whena user opens the host monitoring application if the analyteconcentration older than a predetermined amount, such as 7.5 minutes.

FIG. 2B depicts another example architecture of remote monitoring system100. Referring to FIG. 2B, the receiver 102 may incorporate the gateway104 of FIG. 2A. For example, the receiver 102 may include an interface,such as a radio frequency modem, to network 108A. To illustrate further,in the example of FIG. 2B, the receiver 102 may include a smart phone orother processor-based wireless device and provide access to network 108Aand thus secure server 110 via the public land mobile network and othernetworks (e.g., the Internet).

In addition, while illustrated separately in FIG. 2B, the secure server110 may incorporate the notification service 112 or by-pass thenotification service 112 in some implementations. In suchimplementations, the operation of the system at FIG. 2B may be similarto the process described at FIG. 3 but sensor data 180 may be sent at180 directly to secure server 110, and secure server 110 may send anotification message at 188 directly to the remote monitor 114.

FIG. 2C depicts yet another example architecture of remote monitoringsystem 100. Here, gateway 104 is depicted as a dashed box includingseparate devices comprising a docking station 103 and a hostcommunication device 105. Any of the functions for gateway 104 describedherein can be divided between the docking station and host communicationdevice in some implementations. For example, docking station 103 maycommunicate with receiver 102 and host communication device 105 maycommunicate with the secure server 110.

In some implementations, the host communication device 105 is a smartphone and the docking station 103 physically, electrically andcommunicatively couples to receiver 102 to hold, power and communicatewith the receiver. In one implementation, the docking station 103couples to the receiver via a USB connection to both provide power tothe receiver 102 and communicate with the receiver 102. The dockingstation 103 then communicates with host communication device 105 viawireless communication, e.g. using the Bluetooth® Low-Energy (BLE)protocol, and the host communication device communicates to secureserver 110 via network 108A. Such an implementation including thedocking station 103 may be used in the case where receiver 102 and hostcommunication device 105 do not have the capability to communicatedirectly with one another because, for example, the receiver and hostcommunication device do not use a compatible communication protocol.

In an example of the implementation of FIG. 2C, the host communicationdevice 105 is a mobile telephone having a host monitoring applicationdownloaded from the Apple App Store, wherein the application configuresthe mobile telephone to gather information from receiver 102 via dockingstation 103 and transmit that information to secure server 110, as wellas any other functions described herein associated with gateway 104.

Before providing additional implementation examples for gateway 104,networks 108A-C, secure server 110, notification service 112, and remotemonitor 114, the following provides implementation examples for thereceiver 102, continuous analyte sensor 10, delivery pump 2, and/orglucose meter 4.

Referring again to FIGS. 2A-2C, sensor electronics module 12 may, insome example implementations, include electronic circuitry associatedwith measuring and processing data generated by the continuous analytesensor 10. This generated continuous analyte sensor data may alsoinclude algorithms, which can be used to process and calibrate thecontinuous analyte sensor data, although these algorithms may beprovided in other ways as well. The sensor electronics module 12 mayinclude hardware, firmware, software, or a combination thereof toprovide measurement of levels of the analyte via a continuous analytesensor, such as a continuous glucose sensor. An example implementationof the sensor electronics module 12 will now be described further withrespect to FIG. 5.

The sensor electronics module 12 may, as noted, couple (e.g., wirelesslyand the like) with one or more devices, such as receiver 102 and thelike, presenting (and/or alerting) information, such as sensorinformation transmitted by the sensor electronics module 12 for displayat receiver 102.

As illustrated in FIG. 5, the receiver 102 may include one or moreinterfaces, such as machine-to-machine interfaces and user interfaces.For example, the user interfaces may include a variety of interfaces,such as one or more buttons 124, a liquid crystal display 122, avibrator, an audio transducer (e.g., speaker), a backlight, and/or thelike. The components that comprise the user interface may providecontrols to interact with the user (e.g., the host). One or more buttonsmay allow, for example, toggle, menu selection, option selection, statusselection, yes/no response to on-screen questions, a “turn off” function(e.g., for an alert), a “snooze” function (e.g., for an alert), a reset,and/or the like. The LCD 122 may provide the user with, for example,visual data output. The audio transducer 230 (e.g., speaker) may provideaudible signals in response to triggering of certain alerts, such aspresent and/or predicted hyperglycemic and hypoglycemic conditions. Insome example implementations, audible signals may be differentiated bytone, volume, duty cycle, pattern, duration, and/or the like. In someexample implementations, the audible signal may be configured to besilenced (e.g., snoozed or turned off) by pressing one or more buttons224 on the receiver 102 and/or by signaling the sensor electronicsmodule using a button or selection on the receiver.

Although FIGS. 2A, and 2B depict example implementations of receiver 102as a hand-held display device, other form factors may be used as well,such as a relatively small, key fob-like, dongle-like display device, acellular phone (e.g., a smart phone, a tablet, and the like), a personalcomputer 20, and/or any other user equipment configured to at leastpresent information (e.g., a medicament delivery information, discreteself-monitoring glucose readings, heart rate monitor, caloric intakemonitor, and the like).

In some example implementations, the continuous analyte sensor 10comprises a sensor for detecting and/or measuring analytes, and thecontinuous analyte sensor 10 may be configured to continuously detectand/or measure analytes as a non-invasive device, a subcutaneous device,a transdermal device, and/or an intravascular device. In some exampleimplementations, the continuous analyte sensor 10 may analyze aplurality of intermittent blood samples, although other analytes may beused as well.

In some example implementations, the continuous analyte sensor 10 maycomprise a glucose sensor configured to measure glucose in the bloodusing one or more measurement techniques, such as enzymatic, chemical,physical, electrochemical, spectrophotometric, polarimetric,calorimetric, iontophoretic, radiometric, immunochemical, and the like.In implementations in which the continuous analyte sensor 10 includes aglucose sensor, the glucose sensor may be comprise any device capable ofmeasuring the concentration of glucose and may use a variety oftechniques to measure glucose including invasive, minimally invasive,and non-invasive sensing techniques (e.g., fluorescent monitoring), toprovide a data, such as a data stream, indicative of the concentrationof glucose in a host. The data stream may be raw data signal, which isconverted into a calibrated and/or filtered data stream used to providea value of glucose to a user, such as a host, or a caretaker (e.g., aparent, a relative, a guardian, a teacher, a doctor, a nurse, or anyother individual that has an interest in the wellbeing of the host).Moreover, the continuous analyte sensor 10 may be implanted as at leastone of the following types of sensors: an implantable glucose sensor, atranscutaneous glucose sensor, implanted in a host vessel orextracorporeally, a subcutaneous sensor, a refillable subcutaneoussensor, an intravascular sensor.

Although the description herein refers to some implementations thatinclude a continuous analyte sensor 10 comprising a glucose sensor, thecontinuous analyte sensor 10 may comprise other types of analyte sensorsas well. Moreover, although some implementations refer to the glucosesensor as an implantable glucose sensor, other types of devices capableof detecting a concentration of glucose and providing an output signalrepresentative of glucose concentration may be used as well.Furthermore, although the description herein refers to glucose as theanalyte being measured, processed, and the like, other analytes may beused instead or as well including, for example, ketone bodies (e.g.,acetone, acetoacetic acid and beta hydroxybutyric acid, lactate, etc.),glucagon, Acetyl Co A, triglycerides, fatty acids, intermediaries in thecitric acid cycle, choline, insulin, cortisol, testosterone, and thelike. In some implementations, other health characteristics of a hostare monitored in addition to or instead of analyte monitoring describedherein, including, but not limited to heart rate, blood pressure levels,blood oxygen levels, body temperature, caloric intake, medicamentdelivery and the like.

In one implementation, the sensor system 8 and receiver 102 comprise theDexCom G4® Platinum continuous glucose monitoring system available fromDexCom, Inc., and gateway 104 comprises an Apple iPhone® smartphoneavailable from Apple, Inc. with software downloaded thereon to cause thesmart phone to perform some or all of the functions of gateway 104described herein.

FIG. 5 depicts an example of a sensor electronics module 12, inaccordance with some example implementations. The sensor electronicsmodule 12 may include sensor electronics that are configured to processsensor information, such as sensor data. For example, the sensorelectronics module may process sensor data into one or more of thefollowing: filtered sensor data (e.g., one or more filtered analyteconcentration values), raw sensor data, calibrated sensor data (e.g.,one or more calibrated analyte concentration values), rate of changeinformation, trend information, rate of acceleration information, sensordiagnostic information, location information (which may be provided by alocation module 269 providing location information, such as globalpositioning/navigation system information), alarm/alert information,calibration information, smoothing and/or filtering algorithms of sensordata, and/or the like.

In some example implementations, the sensor electronics module 12 may beconfigured to calibrate the sensor data, and the data storage memory 220may store the calibrated sensor data points. Moreover, the sensorelectronics module 12 may be configured, in some exampleimplementations, to receive wirelessly calibration information from adevice, such as receiver 102, to enable calibration of the sensor data.Furthermore, the sensor electronics module 12 may be configured toperform additional algorithmic processing on the sensor data (e.g.,calibrated and/or filtered data and/or other sensor information), andthe data storage memory 220 may be configured to store the transformedsensor data and/or sensor diagnostic information associated with thealgorithms.

In some example implementations, the sensor electronics module 12 maycomprise an application-specific integrated circuit (ASIC) 205 coupledto a user interface 122. The ASIC 205 may further include a potentiostat210, a telemetry module 232 for transmitting data from the sensorelectronics module 12 to one or more devices, such receiver 102 and thelike, and/or other components for signal processing and data storage(e.g., processor module 214 and data store 220). Although FIG. 2 depictsASIC 205, other types of circuitry may be used as well, including fieldprogrammable gate arrays (FPGA), one or more microprocessors configuredto provide some (if not all of) the processing performed by the sensorelectronics module 12, analog circuitry, digital circuitry, or acombination thereof.

In the example depicted at FIG. 5, the potentiostat 210 is coupled to acontinuous analyte sensor 10, such as a glucose sensor, via data line212 to receive sensor data from the analyte. The potentiostat 210 mayalso provide via data line 212 a voltage to the continuous analytesensor 10 to bias the sensor for measurement of a value (e.g., a currentand the like) indicative of the analyte concentration in a host (alsoreferred to as the analog portion of the sensor). The potentiostat 210may have one or more channels (and corresponding one or more data lines212), depending on the number of working electrodes at the continuousanalyte sensor 10.

In some example implementations, the potentiostat 210 may include aresistor that translates a current value from the sensor 10 into avoltage value, while in some example implementations, acurrent-to-frequency converter may also be configured to integratecontinuously a measured current value from the sensor 10 using, forexample, a charge-counting device. In some example implementations, ananalog-to-digital converter may digitize the analog signal from thesensor 10 into so-called “counts” to allow processing by the processormodule 214. The resulting counts may be directly related to the currentmeasured by the potentiostat 210, which may be directly related to ananalyte level, such as a glucose level, in the host.

The telemetry module 232 may be operably connected to processor module214 and may provide the hardware, firmware, and/or software that enablewireless communication between the sensor electronics module 12 and oneor more other devices, such as receiver 102, display devices,processors, network access devices/gateways, and the like. A variety ofwireless radio technologies that can be implemented in the telemetrymodule 232 include Bluetooth, Bluetooth Low-Energy, the ANT protocol,NFC (near field communications), ZigBee, IEEE 802.11, IEEE 802.16,cellular radio access technologies, radio frequency (RF), infrared (IR),paging network communication, magnetic induction, satellite datacommunication, spread spectrum communication, frequency hoppingcommunication, near field communications, and/or the like. In someexample implementations, the telemetry module 232 comprises a Bluetoothchip, although the Bluetooth technology may also be implemented in acombination of the telemetry module 232 and the processor module 214.Further, while telemetry module is depicted as part of the ASIC 205 inFIG. 2, some or all of the telemetry module can be separate from theASIC in other implementations.

The processor module 214 may control the processing performed by thesensor electronics module 12. For example, the processor module 214 maybe configured to process data (e.g., counts), from the sensor, filterthe data, calibrate the data, perform fail-safe checking, and/or thelike.

In some example implementations, the processor module 214 may comprise adigital filter, such as for example an infinite impulse response (IIR)or a finite impulse response (FIR) filter. This digital filter maysmooth a raw data stream received from sensor 10, data line 212 andpotentiostat 210 (e.g., after the analog-to-digital conversion of thesensor data). Generally, digital filters are programmed to filter datasampled at a predetermined time interval (also referred to as a samplerate). In some example implementations, such as when the potentiostat210 is configured to measure the analyte (e.g., glucose and the like) atdiscrete time intervals, these time intervals determine the samplingrate of the digital filter. In some example implementations, thepotentiostat 210 is configured to measure continuously the analyte, forexample, using a current-to-frequency converter. In thesecurrent-to-frequency converter implementations, the processor module 214may be programmed to request, at predetermined time intervals(acquisition time), digital values from the integrator of thecurrent-to-frequency converter. These digital values obtained by theprocessor module 214 from the integrator may be averaged over theacquisition time due to the continuity of the current measurement. Assuch, the acquisition time may be determined by the sampling rate of thedigital filter.

The processor module 214 may further include a data generator configuredto generate data packages for transmission to devices, such as receiver102. Furthermore, the processor module 215 may generate data packets fortransmission to these outside sources via telemetry module 232. In someexample implementations, the data packages may, as noted, becustomizable and/or may include any available data, such as a timestamp, displayable sensor information, transformed sensor data, anidentifier code for the sensor and/or sensor electronics module, rawdata, filtered data, calibrated data, rate of change information, trendinformation, error detection or correction, and/or the like.

The processor module 214 may also include a program memory 216 and othermemory 218. The processor module 214 may be coupled to a communicationsinterface, such as a communication port 238, and a source of power, suchas a battery 234. Moreover, the battery 234 may be further coupled to abattery charger and/or regulator 236 to provide power to sensorelectronics module 12 and/or charge the batteries 234.

The program memory 216 may be implemented as a semi-static memory forstoring data, such as an identifier for a coupled sensor 10 (e.g., asensor identifier (ID)) and for storing code (also referred to asprogram code) to configure the ASIC 205 to perform one or more of theoperations/functions described herein. For example, the program code mayconfigure processor module 214 to process data streams or counts,filter, calibrate, perform fail-safe checking, and the like.

The memory 218 may also be used to store information. For example, theprocessor module 214 including memory 218 may be used as the system'scache memory, where temporary storage is provided for recent sensor datareceived from data line 212 and potentiostat 210. In some exampleimplementations, the memory may comprise memory storage components, suchas read-only memory (ROM), random-access memory (RAM), dynamic-RAM,static-RAM, non-static RAM, easily erasable programmable read onlymemory (EEPROM), rewritable ROMs, flash memory, and the like.

The data storage memory 220 may be coupled to the processor module 214and may be configured to store a variety of sensor information. In someexample implementations, the data storage memory 220 stores one or moredays of continuous analyte sensor data. For example, the data storagememory may store 1, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 20,and/or 30 (or more days) of continuous analyte sensor data received fromsensor 10 via data line 212. The stored sensor information may includeone or more of the following: a time stamp, raw sensor data (one or moreraw analyte concentration values), calibrated data, filtered data,transformed sensor data, location information, and/or any other sensorrelated or displayable information.

The user interface 222 may include a variety of interfaces, such as oneor more buttons 224, a liquid crystal display (LCD) 226, a vibrator 228,an audio transducer (e.g., speaker) 230, a backlight, and/or the like.The components that comprise the user interface 222 may provide controlsto interact with the user (e.g., the host). One or more buttons 224 mayallow, for example, toggle, menu selection, option selection, statusselection, yes/no response to on-screen questions, a “turn off” function(e.g., for an alert), a “snooze” function (e.g., for an alert), a reset,and/or the like. The LCD 226 may provide the user with, for example,visual data output. The audio transducer 230 (e.g., speaker) may provideaudible signals in response to triggering of certain alerts, such aspresent and/or predicted hyperglycemic and hypoglycemic conditions. Insome example implementations, audible signals may be differentiated bytone, volume, duty cycle, pattern, duration, and/or the like. In someexample implementations, the audible signal may be configured to besilenced (e.g., snoozed or turned off) by pressing one or more buttons224 on the sensor electronics module and/or by signaling the sensorelectronics module using a button or selection on a display device(e.g., key fob, cell phone, and/or the like).

Although audio and vibratory alerts are described with respect to FIG.2, other alerting mechanisms may be used as well. For example, in someexample implementations, a tactile alert is provided including a pokingmechanism configured to “poke” the patient in response to one or morealert conditions.

The battery 234 may be operatively connected to the processor module 214(and possibly other components of the sensor electronics module 12) andprovide the necessary power for the sensor electronics module 12. Insome example implementations, the battery is a Lithium Manganese Dioxidebattery, however any appropriately sized and powered battery can be used(e.g., AAA, Nickel-cadmium, Zinc-carbon, Alkaline, Lithium, Nickel-metalhydride, Lithium-ion, Zinc-air, Zinc-mercury oxide, Silver-zinc, orhermetically-sealed). In some example implementations, the battery isrechargeable. In some example implementations, a plurality of batteriescan be used to power the system. In yet other implementations, thereceiver can be transcutaneously powered via an inductive coupling, forexample.

A battery charger and/or regulator 236 may be configured to receiveenergy from an internal and/or external charger. In some exampleimplementations, a battery regulator (or balancer) 236 regulates therecharging process by bleeding off excess charge current to allow allcells or batteries in the sensor electronics module to be fully chargedwithout overcharging other cells or batteries. In some exampleimplementations, the battery 234 (or batteries) is configured to becharged via an inductive and/or wireless charging pad, although anyother charging and/or power mechanism may be used as well.

One or more communication ports 238, also referred to as externalconnector(s), may be provided to allow communication with other devices,for example a personal computer (PC) communication (com) port can beprovided to enable communication with systems that are separate from, orintegral with, the sensor electronics module. The communication port,for example, may comprise a serial (e.g., universal serial bus or “USB”)communication port, to communicate with another computer system (e.g.,PC, personal digital assistant or “PDA,” server, or the like), a donglewith a wireless transceiver coupled to a docking station as describedfurther below, and/or any other interface. The communication port mayalso be coupled to, or include, a wireless transceiver to allow wirelesscommunications as well. In some example implementations, the sensorelectronics module 12 is able to transmit historical data to a PC orother computing device (e.g., a secure server as disclosed herein) forretrospective analysis by a patient and/or physician.

In some continuous analyte sensor systems, an on-skin portion of thesensor electronics may be simplified to minimize complexity and/or sizeof on-skin electronics, for example, providing only raw, calibrated,and/or filtered data to a display device such as receiver 102 configuredto run calibration and other algorithms described above with respect tothe sensor electronics module 12. However, the sensor electronics module12 may be implemented to execute prospective algorithms used to generatetransformed sensor data and/or displayable sensor information,including, for example, algorithms that: evaluate a clinicalacceptability of reference and/or sensor data, evaluate calibration datafor best calibration based on inclusion criteria, evaluate a quality ofthe calibration, compare estimated analyte values with timecorresponding measured analyte values, analyze a variation of estimatedanalyte values, evaluate a stability of the sensor and/or sensor data,detect signal artifacts (noise), replace signal artifacts, determine arate of change and/or trend of the sensor data, perform dynamic andintelligent analyte value estimation, perform diagnostics on the sensorand/or sensor data, set modes of operation, evaluate the data foraberrancies, and/or the like.

Although separate data storage and program memories are shown in FIG. 5,a variety of configurations may be used as well. For example, one ormore memories may be used to provide storage space to support dataprocessing and storage requirements at sensor electronic module 12.

Although some of the examples noted refer to a continuous analyte sensor10, a glucose meter 4, and pump 2 in communications with sensorelectronics module 12 and/or receiver 102, other devices may be used aswell. For example, sensor electronics module 12 and/or receiver 102 maycouple (either via wired and/or wireless links) to other sensors,including a glucose sensor, an altimeter, an accelerometer, atemperature sensor, a location module (e.g., a global positioning systemprocessor or other source of location information), a heart ratemonitor, a blood pressure monitor, a pulse oximeter, a caloric intakemonitor, a medicament delivery device, and the like.

As noted above, the sensor electronics module 12 may generate andtransmit, via a wireless or wired medium, a data package to a device,such as receiver 102, configured to receive, store, forward/retransmit,and/or display sensor data. The sensor electronics module 12 may, asnoted, analyze the sensor data from the multiple sensors and determinewhich sensor data is to be transmitted based on one or more of manycharacteristics of the host, the receiver 102, a user of the receiver102, a remote monitor 114, and/or characteristics of the sensor data.Moreover, one or more of the functions and/or components describedherein with respect to the sensor system 8 may also or instead be foundone or more of the receiver 102, gateway or secure server 110, and theone or more of the functions described herein with respect to thereceiver 102 may also be found on the sensor system 8.

Referring again to FIG. 2A for purposes of illustration, the receiver102 may forward analyte sensor data, as well as other available data,via wired and/or wireless links to gateway 104. In some exampleimplementations, the gateway 104 may include a network interfaceconfigured as a radio interface, such as a cellular radio interface(e.g., Long Term Evolution and the like), a wireless local area networkinterface (e.g., Wi-Fi and the like), and/or any other type of wirelessor wired interface. For example, the gateway 104 may include at leastone processor including a radio frequency subsystem (e.g., a modem). Inthese wireless examples, when the receiver 102 couples to gateway 104,the gateway 104 sends analyte sensor data and the like wirelessly tosecure server 110 via network 108A, which may include one or more of anaccess network, a wireless local area network, a radio access network, acellular network, the Internet, and/or any other communicationmechanism. In some example implementations, gateway 104 may also includea wired connection network 108A, which further couples to secure server110.

Gateway 104 can automatically send sensor analyte data and additionalinformation from receiver 102 in one or more of a plurality of ways. Forexample, receiver 102 can provide gateway 104 with information without arequest from gateway. The information can be provided automatically,such as after the expiration of a timer or upon the generation of a newsensor data point, or can be responsive to user input to receiver 102.Gateway 104 can then automatically send the information from receiver tosecure server 110. In another example, gateway can automatically requestinformation based upon predetermined rules, such as after the expirationof a timer, such as a 5 minute timer. The information provided by thereceiver 102 can then be automatically sent to secure server 110. In yetanother example, gateway may send a request for information to gateway104 which then forwards the request to receiver 102. The receiver 102can then provide the requested information to gateway, which thenforwards the information to secure server 110. In each of theseexamples, the information requested can be for specific information(e.g., a specific time period of sensor data) or simply a generalrequest to send information. In the latter case, the receiver 102 candetermine what information to send responsive to the request, such asany new sensor data generated by receiver since the receiver lastprovided information to the server 110.

FIG. 6 is a block diagram of an implementation of gateway 104. Thegateway 104 can include a power module 302 for charging the receiver 102when it is coupled to the gateway 104, a wireless network interface 304to allow wireless access to network 108A using a variety of networkaccess technologies, although wired connectivity may also be provided bygateway 104 to network 108A, processor 414 and computer memory forstoring instructions for processor 314 to execute functions of gateway104 and storing health-related information received from receiver 102.

Moreover, the gateway 104 can include a receiver interface 306 toprovide a wired and/or wireless interface to the receiver 102 inimplementations where the receiver is separate from the gateway and thegateway does not include intermediate docking station 103. For example,receiver interface 306 may include a universal serial bus interfacethrough which receiver 102 can communicate with gateway 104, secureserver 110, and the like. The universal serial bus may also provide aphysical connection for charging the receiver 102, although wirelesscharging may be used as well. Furthermore, receiver interface 306 mayinclude a wireless interface, such as Bluetooth, Bluetooth low energy,Zig-bee, Atom, and any other wireless technology, through which receiver102 can communicate with gateway 104, secure server 110, and the like.The gateway 104 may also include a user interface 310, such as adisplay, a touch screen display, a key pad, a speaker, a light emittingdiode, and the like. For example, one or more light emitting diodes maybe used to indicate whether the gateway 104 is properly coupled to thereceiver 102, network 108A, secure server 110, and the like, whether thegateway 104 is connected to a power source (e.g., electrical outlet),whether the battery is charged, and the like. The display may also allowpresentation of sensor data, alerts, notifications, and the like. Forexample, a user interface, such as a display, a light emitting diode,and the like, may provide an indication, such as a specific color lightemitting diode, a message, and the like, representing that a connection,such as an Internet Protocol connection, a secure tunnel, and the like,has been establish between the gateway 104 and the secure server 110, sothat the user of the gateway 104 recognizes that the receiver is coupledto the so-called “cloud” which includes the secure server 110.

As discussed above, in some implementations, gateway 104 can comprise asmart phone having a host monitoring application stored thereon thatconfigures the smart phone to perform the functions of gateway 104described herein.

FIGS. 7A and 7B depict an example of the docking station 700, which canbe the docking station 103 described with respect to of FIG. 2C. FIG. 7Aillustrates a perspective view of the docking station 700 withoutreceiver 102 physically coupled to the docking station, and FIG. 7Billustrates a front view of docking station with receiver 102 physicallycoupled to the docking station. Docking station 700 may have a cavity710 to allow receiver 102 to be slideably inserted and releasably heldinto the docking station. The docking station 700 may also include amechanical mechanism to releasably secure the receiver 102 to thedocking station (not shown). The mechanism can be a latch assembly orthe like. The docking station may electrically couple to the receiver102 via, for example, an electrical connector, such as a universalserial bus connector, and/or a wireless interface, such as Bluetooth,Bluetooth low-energy, Wi-Fi, and any other wireless technology, and maytransmit data received from the receiver 102 to host communicationdevice 105, secure server 110 or remote monitor 114 using an electricalconnector, and/or a wireless interface, such as Bluetooth, Bluetoothlow-energy, Wi-Fi, and any other wireless technology.

The docking station 700 may also serve as a repeater and/or amplifier ofany alert triggered by the receiver 102 and/or secure server 110. Forexample, the docking station 103 may receive an indication of an alerttriggered by the receiver 102 from the receiver. The docking station 700may repeat the alert by, for example, sounding an audible alarm, causinga vibration, and/or lighting a light emitting diode to indicate thealert to a user. Moreover, the receiver 102 may alert using a firstalarm, such as a vibration, while the docking station 700 may re-alertusing a second type of alarm that is different from the first alarm. Forexample, the first alarm can be a vibratory alarm and the second alarmcan be an audible alarm or vice versa. As another example, the firstalarm can be an audible alarm and the second alarm can also be anaudible alarm, but the second audible alarm is louder than the firstalarm and/or has a different tonal pattern.

In some implementations, the docking station 700 can trigger an alert byphysically sensing an alarm from the receiver 102. For example, thedocking station can include a vibratory and/or audible sensor that cansense vibrations or sounds, respectively, emanating from receiver 102.In this way, the docking station 103 can trigger an alert upon sensingthe receiver 102 triggering an alarm while the receiver is docked in thedocking station.

Furthermore, the alert settings at the docking station 700 may be thesame or different as those at the receiver 102. For example, alertsettings at docking station 700 may be more stringent than those at thereceiver 102. For instance, the receiver 102 may have a low glucosethreshold at a value that is greater than a corresponding low glucosethreshold at the docking station 700. The alert settings of the dockingstation 700 can be user configurable using a user interface of thedocking station or a user interface of the host communication device105, for example.

Additionally or alternatively, in some implementations the dockingstation 700 delays triggering an alert that was triggered by receiver102 to allow the host time to cure the alert prior to the dockingstation triggering an alarm. Should the host cure the alert prior to theexpiration of the delay, then the docking station 700 does not triggerthe alert.

Further to FIGS. 7A and 7B, the docking station 700 can include one ormore light indicators, such as LEDs, that indicate a status of thedocking station 700 and/or other components of the system 100. Forexample, a first light indicator 712 can indicate (by either turning onor changing color) if the docking station 700 is receiving power from anexternal power source, a second light indicator 714 can indicate (byturning on, changing color or blinking) if the docking station is pairedto host communication device 105. Other light indicators can be used aswell, such as a third light indicator that indicates if thecommunication channel between docking station 700 and host communicationdevice 105 and/or secure server 110 is open and successfullytransmitting sensor data from receiver 102.

FIG. 8 depicts another implementation of gateway 104. In the example ofFIG. 8, the gateway 104 is configured as a dongle, such as a universalserial bus dongle, including universal serial bus connector 392 forcoupling to the receiver 102, a user interface, such as a button 394 forperforming a Bluetooth pairing to another device, such as host device105, having access to network 108A, or directly to network 108A over aWi-Fi or cellular communication channel. Although the gateway/dongle maybe configured for Bluetooth pairing, the gateway/dongle may supportconnection establishment to the other devices using other radio accesstechnologies, such as Bluetooth low energy, Wi-Fi, Atom, Zig-bee, NFC,and the like. The gateway/dongle depicted at FIG. 8 may also include alight emitting diode 396 for providing an indication of the state of thegateway 104 or receiver 102 (e.g., battery level, glucose level status,whether a user is in a low or high glycemic state, connection status tonetwork, connection status to secure server, and the like). In someexample implementations, the gateway at FIG. 8 may include its ownrechargeable battery to power the gateway and/or the receiver 102,although it may rely on the receiver 102 as a power source as well.

In some example implementations, the gateway 104 may, as noted, includea radio frequency interface to allow the data to be automaticallyuploaded in a compressed format or uncompressed format from the receiver102 to the secure server 110, which may be implemented as a so-called“cloud.” And, the uploading may occur programmatically—without userintervention—when receiver 102 is in communication with gateway 104. Thegateway 104 may also be configured to gather an identifier of thereceiver 102 (or the receiver may automatically provide the identifierwithout a request for the identifier from the gateway 104) and providethe identifier to the secure server 110 to allow the secure server 110to associate the received sensor data with the host 199, receiver, andany previously provided sensor data stored at secure server 110 (or arepository coupled to secure server 110) associated with the host. Insome implementations, the identifier is the serial number of thereceiver 102, and the receiver automatically sends the identifier alongwith any sensor data the receiver provides to gateway. In someimplementations, the identifier is the serial number of the associatedwith the sensor electronics 12 and/or sensor system 8. Moreover, in someexample implementations, the gateway 104 may be configured to send dataincrementally, i.e., data previously received would not be re-sent tosecure server 110 unless requested by secure server 110. Furthermore,gateway 104 may select between a cellular connection and a Wi-Ficonnection based on connection speed, cost, and the like. For example, afree Wi-Fi connection may be selected over a fee-based cellularconnection if available. Further, a cellular connection may be used forsending substantially real-time data generated by sensor system 8, but aWi-Fi connection used for sending historical data, as it may not be asimportant for sending historical data in a timely fashion in someimplementations.

In some example implementations, the gateway 104, receiver 102, sensorsystem 8, and remote monitor 114 may be preconfigured, so that when thesensor system 8 and receiver 102 communicatively couple to gateway 104,the gateway 104 recognizes the sensor system/receiver and/or usersthereof. Further, the remote monitor 114 may also be recognized byserver 110 to allow remote monitoring of receiver 102 to occur withlittle (if any) configuration by an end-user/host of receiver 102. Forexample, the secure server 110, gateway 104, receiver 102, sensor system8, and remote monitor 114 may be preconfigured and preregistered, withlittle, if any, configuration or registration effort on the part of thehost.

Referring again to FIGS. 2A-2C, the network 108A may include a wirelessaccess network, such as a cellular network, a wireless local areanetwork, and the like. In addition, network 108A may couple to othernetworks as well. For example, the gateway 104 may couple to an accessnetwork served by a base station or a Wi-Fi access point, which may havebackhaul links to other networks including the public land mobilenetwork, the Internet, and the like. Networks 108B-C may be implementedin a manner that is the same or similar to network 108A.

The secure server 110 may receive analyte sensor data, store analytesensor data, process analyte sensor data to detect events and thus allowgeneration of notifications to remote monitors 114 and/or generation ofalerts to receiver 102 and/or gateway 104, generate pages or reports fordisplay at remote monitor 114, receiver 102 and/or gateway 104, allowregistration and/or configuration of host 199, sensor system 8, receiver102, gateway 104 and remote monitor 114.

In some example implementations, one or more entities may have remotemonitors 114A-114M. For example, the secure server 110 may register theidentity of the users of remote monitors 114A-114M and a schedule forwhen each entity performs monitoring. Moreover, one or more of theentities may be configured at the secure server 110 as primary monitorsfor receiving notifications, while other entities may be configured asbackup, secondary monitors for receiving notifications when a primarymonitor does not acknowledge, or act on the, notification message sentto a remote monitor 114 according to one or more predefined rules.Furthermore, the secure server 110 may include one or more rulesdefining when an event results in a notification to one or more of theremote monitor(s) 114.

The secure server 110 may also provide a cloud-based diabetes datamanagement framework that receives patient-related data from variousdevices, such as a medical device, a glucose meter, a continuous glucosemonitor, a sensor system, a receiver, and/or other devices (e.g., adevice providing food consumption, such as carbohydrates, consumed by ahost or patient, medicament delivery data, time of day, temperaturesensors, exercise/activity sensors, and the like) including any devicedisclosed herein. Furthermore, the cloud-based diabetes data managementsystem may receive data programmatically with little (or no)intervention on the part of a user. The data received from devices,receivers, source systems, and the like may be in a variety of formatsand may be structured or unstructured. For example, the secure server110 may receive, from sensor system 8 and receiver 102, raw sensor data,which has been minimally processed or analyzed, and the received data isthen formatted, processed (e.g., analyzed), and/or stored in order toenable report generation by secure server 110. In addition to sensordata, the secure server 110 may also receive data from source systems,such as health care management systems, patient management systems,prescription management systems, electronic medical record systems,personal health record systems, and the like.

In some example implementations, the secure server 110 may checkreceived data for transmission-related errors, data formatting,device-related error codes, validity of the data, duplicate data points,and/or other aspects of the data. Moreover, if out-of-range data pointsor device errors are found, the secure server 110 may identify thosedata points by, for example, flagging those data points, subsequentlycorrecting the identified data points programmatically or by a systemadministrator, and storing the corrected data points. Moreover, secureserver 110 may be configured by a user, such as a clinician, doctor, andthe like, to perform additional data processing steps, such ascorrecting time of day, correcting the date, and analyzing data byspecific cohorts, groups, and relationships (e.g., demographics, such asage, city, state, gender, ethnicity, Type I diabetes, Type II diabetes,age of diabetes diagnosis, lab results, prescription drugs being used,self-reported conditions of the patient, diagnosed conditions of thepatient, responses to questions posed to patient, and any other metadatarepresentative of the host/patient). Once secure server 110 performsinitial data processing (e.g., checks, cleaning, and analysis), theprocessed data and/or the raw data may be stored at a repository coupledto the secure server 110.

The processing at secure server 110 may also include associatingmetadata with the data received from the devices and/or sensors.Examples of metadata include patient information, keys used to encryptthe data, patient accelerometer data, location data (e.g., location ofpatient or location of patient's clinic), time of day, date, type ofdevice used to generate associated sensor data, and the like. Thepatient information can include the patient's age, weight, sex, homeaddress and/or any past health-related information, such as whether thepatient has been diagnosed as a Type 1 or Type 2 diabetic, high-bloodpressure, or as having any other health condition.

The processing may also include one or more of the following: analysis,such as determining one or more descriptive measurements; detecting orpredicting events (e.g., a hypoglycemic, a hyperglycemic, and/or anyother feature detected in the sensor data); applying pattern detectorsto the received sensor data; and generating reports based on receivedinformation, such as sensor data, and descriptive measurements of theinformation including sensor data. The descriptive measurements mayinclude statistics (e.g., median, inner, and outer quartile ranges,mean, sum, n, standard deviation, and coefficients of variation). Insome example implementations, secure server 110 may also associatemetadata with the data received from the devices, sensors, sourcesystem, and/or receivers; determine one or more descriptivemeasurements, such as statistics (e.g., median, inner and outer quartileranges, mean, sum, n, and standard deviation); generate reportsincluding descriptive measurements; validating and verifying theintegrity of the received data from the devices, sensors, source system,and/or receivers; processing received data based on metadata (e.g., toselect certain patients, devices, conditions, diabetic type, and thelike), and/or correlating received data from the devices, sensors,source system, and/or receiver, so that the data can be compared andcombined for processing including analysis. Moreover, the results of anyprocessing performed by secure server 110 may be used to generate one ormore reports, such as graphs, bar graphs, static charts, charts, and thelike. Furthermore, the reports and other outputs generated secure server110 may be provided to receiver 102, remote monitor 114, and any otherprocessor via one or more delivery mechanisms.

Secure server 110 may be considered secure in the sense that it keepsprivate, patient identifiable information and/or restricts access tousers registered and thus authorized to use secure server 110. Forexample, secure server 110 may receive a request from a device, such asreceiver 102 or remote monitor 114, to perform an action (e.g., providedata, store data, analyze/process data, request a report, requestconfiguration information, request registration, and the like). Beforesecure server 110 services the request, the secure server 110 mayprocess the request to determine whether the request is authorized andauthenticated. For example, an authenticator and authorizer maydetermine whether the sender of the request is authorized by requiring auser to provide a security credential (e.g., a user identifier, apassword, a stored security token, and/or a verification identifierprovided by text message, phone, or email) at a user interface presentedon a processor, such as receiver 102, remote monitor 114, and/or anyother computer. If authorized, authenticator and authorizer mayauthenticate the sender of the request to check whether a securitycredential associated with sender of the request indicates that thesender is indeed permitted to access a specific resource at system 100in order to perform the action, such as store (or upload) data at arepository, perform analyze/process data, request report generation,receive alerts, receive notification messages, and the like.

In some example implementations, the secure server 100 may include apattern detector to perform pattern detection on data, such as sensordata representative of blood glucose data, analytes, and other data aswell (e.g., insulin pump data, carbohydrate consumption data, and thelike). The pattern detector may detect the pattern and generate anoutput, which may be provided to a report generator at secure server forgenerating an alert to receiver 102, a notification message to remotemonitor 114, and/or a page containing a report.

Moreover, the pattern detector may detect patterns in data/sensor dataretrospectively for a predetermined time defined by system 100 and/or auser. For example, the pattern detector may receive input data from arepository coupled to secure server 110, and the input data may includesensor data representative of glucose concentration data, analytes, andother data as well (e.g., insulin pump data, carbohydrate consumptiondata, histograms and/or counts, data from a continuous glucose monitor(CGM data), time of day, amount of carbohydrates, other food relatedinformation, exercise, awake/sleep timer intervals, medicationsingested, and the like). Moreover, the input data may comprisehistorical data obtained over a timeframe, such as 8 hours, 1 day, 2days, 7 days, 30 days, and/or any other time period. For example, theinput data may comprise counts representative of monitored analytedetection levels (e.g., glucose concentration levels) received andstored at system 100 over a period covering a four-week timeframe.

To further illustrate the pattern detector, patterns can be recognizedbased on one or more predefined triggers (also referred to as criteria,rules, and filters). Furthermore, the one or more predefined triggersmay be variable and adjustable based user input and/or programmaticallybased on one or more rules at the secure server 110. And, some types ofpatterns may be selected, turned off and on, and/or modified by a user,a user's physician, or a user's guardian, although system 100 mayselect, adjust, and/or otherwise modify triggers programmatically aswell.

Some examples of the types of relationships in the input data that canbe considered a pattern are one or more of the following: a glucoselevel that exceeds a target glucose range (which may be defined by auser, a health care provider, secure server 110, or a combinationthereof); a glucose level that is below a target glucose range; a rapidchange in glucose level from a low to a high (or vice versa); times ofday when a low, a high, an at range, or rapid glucose level eventoccurs; days when a low, a high, an at range, or a rapid glucose levelevent occurs; a hyperglycemic pattern; a hypoglycemic pattern; patternsassociated with a time of day or week; a weighted scoring for differentpatterns based on frequency, a sequence, and a severity; a customsensitivity of a user; a transition from a hypoglycemic to hyperglycemicpattern; an amount of time spent in a severe event; a combination ofglucose change and time information; and/or a pattern of highvariability of glucose data. Further, a pattern may be based on acombination of previous pattern data and a currently detected situation,whereby the combined information generates a predictive alert.

Hypoglycemic patterns by time of day may be detected based on eventsdetected by secure server 110. For example, a pattern may be identifiedin situations where the user has low glucose concentrations around thesame time in the day. Another type of pattern, which may be identified,is a “rebound high” situation. For example, a rebound high may bedefined as a situation where a user overcorrects a hypoglycemic event byoverly increasing glucose intake, thereby going into a hyperglycemicevent. These events may be detected based on one or more predefinedtriggers.

To further illustrate examples of the patterns, basic patterns may beconfigured to allow a search for certain patterns in the data, such asvalues within range, high coefficient of variance, and the like. Eachpattern may have one dimension, such as within range, with a separatepattern looking specifically for below range, another looking for lowcoefficient of variance, and the like. Each pattern may be statisticallybased and use standard descriptive statistics in the application ofpattern matching. Each pattern may be assigned scores for various rulesencoded with each pattern, such as is it positive, negative, howimportant an insight is, and the like. Each pattern may also be assigneda possible set of date ranges for which the pattern is applicable. Forexample, counting the number of times a high glucose value is followedby a low below range is a pattern that just applies to the full range.However, looking at high levels of variance can apply to a month, aweek, a day, an intraday, every other hour, hourly, and combinationsthereof. Every pattern may be assigned a minimally acceptable scorebefore it can be considered for display or generation of an alert sentto the receiver 102 (or host 199) and/or notification message sent toremote monitor 114. Each pattern (and any associated triggers/rules) maybe processed for a set of data for a certain timeframe, and if thepattern is applied and meets certain minimal requirements, then thepatterns are ranked according to significance. As such, the rankedpatterns may each correspond to an alert sent to the receiver 102 (orhost 199) and/or notification message sent to remote monitor 114 (or aprimary monitor or secondary monitor access the remote monitor 114).

Further to FIG. 1, host monitoring system 198A may have a single remotemonitor 114A or a plurality of remote monitors 114A-114M, and the rulesassociated with when the remote monitors receive alerts and what typesof alerts should be sent may be stored at the secure server 110. Forexample, first remote monitor 114A may receive notification messagesduring the day, while second remote monitor 114B may receivenotification messages at night, although other schedules may be used aswell. Additionally or alternatively, first remote monitor 114A may onlyreceive notifications when server identifies host system 198 to be at apredefined geographic location (using, e.g., geo-location informationprovided by host system 198), such as a school, while second remotemonitor 114B receives notifications regardless of the geographiclocation of the host. As another example, first remote monitor 114A mayhave high and low threshold values that trigger an alert to remotemonitor 114A that are different than one or both of the high and lowthreshold values that trigger an alert to remote monitor 114B. Moreover,one or more rules may define first remote monitor 114A as a primarymonitor, while second remote monitor 114B may be defined as a backup orsecondary monitor.

The remote monitor 114 may acknowledge a received notification messageby activating (e.g., opening, interacting with, accessing, selecting,and the like) the remote monitoring application which causes a messageto be sent at 194 (FIG. 3) to the secure server 110 or responding to amessage presented at the user interface of the remote monitor. If thesecure server 110 does not receive any form of acknowledgement that theuser has seen or otherwise acknowledged the notification message at theremote monitor after a predetermined amount of time (which may depend onthe severity or type of the event), the secure server 110 may resend thenotification to the remote monitor 114. In some example implementations,the secure server 110 may receive a message from the notificationservice 112 that the remote monitor 114A is out of service or otherwiseunreachable, in which case the secure server 110 may resend thenotification message to a different remote monitor 114B. The delay usedby the secure server for resending the notification messages may beconfigured based on the severity or type of the event, and the secureserver may also include rules defining a predetermined quantity ofunsuccessful resends or predetermined amount of time before escalationto another primary monitor, a secondary/backup monitor, an emergencymedical service, and the like. And, this predetermined quantity ofunsuccessful resends may also be configured at the secure server to varybased on severity or type of the event or user configured.

In some example implementations, with reference to FIG. 1, the remotemonitor 114 may receive notification messages for a single hostmonitoring system 198A or a plurality of host monitoring systems198A-198N. Furthermore, a page may be generated by secure server 110 andthen sent to the one or more remote monitors for presentation at a userinterface at each of the remote monitors, although the secure server 110may instead send the data to the remote monitor 114 to enable pagegeneration at the remote monitor 114. The page may include a textualand/or a graphical indication of the status of the one or more hostsbeing monitored. To illustrate, a school nurse may have a remote monitor114 with a page depicting each of the host monitoring systems 198A theremote monitor is monitoring. Each remote monitoring system 198A-198Nmay be associated with a student. In this example, the page may have thestatus information for each of the students, the most recentnotification message for each of the students, a graphical or a textualindication that the student is within limits, or an indication that thestudent is above limits, and the like. Each student may be associatedwith a cell (a defined space on the display). As such, the nurse mayquickly view the user interface and see the status of each of thestudents being monitored. A graphical indication may be used to visuallyconvey the overall status of each student in each student's cell. Forexample, a so-called “smiley” face icon may indicate the student'sglucose levels are within limits and a so-called “sad” face icon mayindicate the host's glucose levels are of concern because they are abovea threshold. Moreover, in some example implementations, the page may bepresented on a display, so that a selection (e.g., touch on a touchscreen, mouse over, click, etc.) of a cell, notification or face iconresults in additional information being provided to the remote monitor.For example, selecting a cell of a student may cause the remote monitor114 to access the secure server 110 and then receive additionalinformation, such as one or more of current and prior glucose levels,patient information, and the like, and update the display page ortransition to a new display page that displays information about theselected student in more detail (e.g., displaying a trend graph of thestudent's glucose level over the past three hours). Although theprevious example refers to glucose levels and specific types of messagesand icons, other types of events, messages, and icons discussed hereinmay be used to convey the status of a host.

Dashboard

In some example implementations, the page discussed above may beconfigured as a so-called “dashboard” including dynamic content. Forexample, the icons for the host-patients requiring the greatest care orattention (e.g., the patients with glycemic levels that are extremelyhigh or low) may be arrange in the top row of page to allow the remotemonitor to quickly ascertain the state of riskier host patients.Although the previous arrangement described using the top row of thepage to segregate some of the so-called riskier host-patients othersegregation schemes may be used (e.g., different colors, intensities,and/or locations on the page). Furthermore, the page may be considereddynamic as the patients segregated for extra attention may change overtime causing the page to depict different icons for different patientsin the segregated top row of the page. Examples of dashboards arediscussed in greater detail with respect to FIGS. 18A and 18B.

Designating Remote Monitors

In some example implementations, an entity, such as a user, may bedesignated by secure server 110 as a primary remote monitor. When thisis the case, the primary monitor at remote monitor 114 may not beavailable due to for example a dead battery of the remote monitoring114A, a device out of service, a lack of radio reception, and the like.A secondary remote monitor may thus be designated by secure server 110to receive the notification message, which would otherwise be sent tothe primary monitor. The secondary monitor may have access to anotherremote monitoring device 114B and thus receive the notification message,when the first notification message to the primary monitor is notreceived or acknowledged within a predetermined amount of time. Theamount of time can be variable based on the severity or type of event.In addition to monitoring acknowledgements from the remote monitor 114,the secure server 110 may access the quality of service mechanisms atthe notification service 112 to determine whether the remote monitor 114device is not in service (e.g., due to a failure, a dead battery, out ofrange, or otherwise not accepting notification messages) to enable thesecure server 110 to select another monitor that is in service.

Escalation

The remote monitor 114 may, in some example implementations, generate amessage for presentation requiring some form of acknowledgement oraction by the user of the remote monitor 114 (e.g., a primary orsecondary monitor) to confirm receipt of a notification message. Theacknowledgement or action may comprise responding to the notificationmessage, opening a remote monitoring application at the remote monitor114, and the like. Moreover, if the action is not performed within apredetermined amount of time, the secure server 110 may determine thatthe user of the remote monitor has not seen (or otherwise been notifiedby) the notification message. When this is the case, the secure servermay escalate the notification message to another remote monitor asdefined by one or more rules at the secure server. The secure server mayalso check the push notification service (or quality of servicemechanism therein) to see if the notification message has beendelivered. If not, the secure server may determine that the user of theremote monitor has not seen the notification message and use this as abasis to escalate the notification message to another remote monitor.

In some implementations, the secure server 110 may include one or morerules defining an escalation sequence defining which notificationmessages should be sent to first remote monitor 114A and, given an outof service state, when the messages should be resent to one or moreother remote monitors 114B-114M. During configuration of the remotemonitors 114A-114M, the secure server 110 may be configured via userinput (e.g., the host and/or one or more of the remote monitors) howand/or when each of remote monitors 114A-114M is to be notified in anescalation sequence. This escalation sequence configuration may bedefined by a user or provided as a default setting (which may bereconfigurable or adaptable over time based on the responsiveness of theuser/host/monitor) and may vary based on severity of the event and typeof event. For example, the escalation sequence may define rules definingwhen to alert a host-patient at a receiver 102, when to escalate to aprimary monitor 114A, when to escalate to a secondary remote monitor114B, and/or when to escalate to an emergency medical service or911-emergency response.

In some example implementations, the escalation rules may be differentfor each of the remote monitors 114A-114N and/or different from thethresholds set for the host monitoring system 198. For example, a firstrule may define that if a glucose value exceeds a first threshold value,the secure server 110 should send an alert to first remote monitor 114A.The secure server 110 may include a second, separate rule that definessending a notification message to a second remote monitor 114B when theglucose value exceeds a second threshold value, and yet another thirdrule that defines sending another notification message to a third remotemonitor 114M when the glucose value exceeds a third threshold value. Inaddition, a rule may define sending a notification to more than oneremote monitor, such as all remote monitors or a subset of the remotemonitors monitoring a host. The rules may be configured by a user (e.g.,using receiver 102, gateway 104, workstation 22, etc.) or provided asdefault settings (which may be reconfigurable by a user).

Furthermore, if a user at the receiver 102 does not acknowledge an alertwithin a predetermined amount of time, an escalation sequence may alsobe implemented. For example, referring to FIG. 2A, the secure server 110may determine (e.g., by monitoring sensor data received from receiver102 and knowing the thresholds on the receiver) that receiver 102alerted (or should have alerted) host 199, where the alert required anacknowledgement. The acknowledgement can be in the form of a userresponding to a message presented on a user interface 122 of receiver102, or the user otherwise curing the alert, such as taking an actionthat can be measured by a device associated with the host-user (e.g.,medicament pump 2 indicating that insulin has been administered to theuser, an analyte measurement indicating that the underlying cause of thealert is no longer a problem because measured level above a threshold ortrend moving in a desired direction, etc.). In this example, if thesecure server 110 does not receive some form of acknowledgement and/oran indication of the underlying event that triggered the alert is curedafter waiting a predetermined amount of time, the secure server 110 mayresend the alert and/or send a notification message to a primary remotemonitor (e.g. 114A), a secondary remote monitor (e.g. 114B), and/or anemergency medical service. And, this escalation, including the retriesand delay, may be configured at the secure server 110 to vary based onthe severity and/or type of event triggering the alert.

Reminders

In some example implementations, the secure server 110 may include rulesproviding a so-called “follow-up” reminder. For example, if a host-userat receiver 102 has not taken an action, such as take insulin, drink aglass of juice, etc., the secure server 110 may send a remindernotification to the remote monitor 114 and/or to the receiver 102 and/orgateway 104 after a predetermined amount of time. The predeterminedamount of time and which of the one or more of remote monitors114A-114M, receiver 102, gateway 104 associated with a reminder may beconfigurable and may vary based on severity of the event and/or type ofevent.

Furthermore, in some implementations, the secure server 110 may re-sendnotifications repeatedly (e.g., every 5 minutes or any other time) toremote monitor 114 and/or receiver 102 until the receipt of thenotification message is acknowledged. In some example implementations,the secure server 110 may configure different alarm types to betriggered by the receiving device (e.g., remote monitor 114 or receiver102) as each re-send is sent to the receiving device (e.g., successivelyincreasing volume, brightness, or vibration with each repeated,unacknowledged notification message, or triggering a vibratory alarmwith a first reminder and a vibratory alarm with a second reminder,etc.). Opening a message from the secure server 110 at receiving devicemay serve as an acknowledgment, as well as other actions detectable bythe secure server.

In some example implementations, a user designated as a primary monitormay signal to secure server 110 an inability to provide monitoring bysending a message to secure server 110 and/or receiver 102, using, forexample, remote monitor 114A or workstation 22. When this is the case,the secure server 110 may demote the primary monitor to a secondary (orbackup monitor) and promote one of the secondary monitors to a primarymonitor. The secure server may have rules defining which of thesecondary monitors may be promoted or each of the secondary remotemonitors may be polled to assess availability to assume the role ofprimary remote monitor. And, the secure server 110 may send a message(via notification service, for example) to the secondary monitor thathas been promoted to a primary monitor that it has been designated as aprimary monitor (and send a corresponding message to a demoted primarymonitor).

To assure quality of service with respect to the receipt by the remotemonitors of notification messages, one or more operations may beperformed to mitigate the potential loss of a notification message sentto remote monitor 114. For example, if notification service 112comprises a push notification service (e.g., Apple Push NotificationServer, Google Cloud Messaging Server, and the like) and thenotification service cannot be contacted (or a connection cannot beestablished between secure server 110 and notification service 112), thesecure server 110 may send notification via another mechanism, such aseparate a short message service (SMS) message directly to the remotemonitor 114, a phone call, an email, or any other mechanism to establishcontact with the remote monitor(s) and/or the users associated withthose remote monitoring devices.

Registration/Invitations for Remote Monitoring

As noted above, in some example implementations, the devices used atsystem 100 may be required to register with the secure server 110. Toillustrate, with respect to FIG. 2B, the receiver 102 (which may beimplemented on a processor-based wireless device, such as a smart phoneor a tablet computer) may send a message via the public land mobilenetwork or other network(s) to invite remote monitor 114 to accept aconnection establishment request from secure server 110. If accepted,remote monitor 114 may be provided with notification messages for eventsassociated with receiver 102 and access to sensor data and reportsassociated with host 199. Although the previous example describes thereceiver 102 sending an invite to remote monitor 114, other devices,such as secure server 110, gateway 104, user communication device 105,workstation 22, and/or remote monitor 114, may send invitations as wellor instead, depending upon the implementation.

In some example implementations, the receiver 102 may send a pluralityof invitations to each of a plurality of remote monitors 114A-114M.Moreover, the invitations may be managed by the receiver 102, gateway104, user communication device 105 and/or secure server 110, so that atany given instant of time, a user can monitor the status of invitations,such as how many invitations have been sent, how many have beenaccepted, how many have been rejected, and the identity of any primaryand secondary remote monitors. For example, receiver 102 gateway 104,user communication device 105 and/or secure server 110 may manage theinvitations, so that at any given instant, a quantity of remote monitors114A-114M does not exceed a threshold amount (e.g., 5 or 10 remotemonitors).

Moreover, the receiver 102, gateway 104, user communication device 105and/or secure server 110 may also manage the quantity of remote 114monitors based on location and/or time, so that a host-user has apredetermined quantity of remote monitors 114 at any given locationand/or any given time.

In some example implementations, a host 199 or caretaker of host maymanage the status of invitations (e.g., invitation sent, invitationaccepted, monitoring cancelled, and the like) via receiver 102, gateway104, user communication device 105 and/or secure server 110. Forexample, one or more user-interactive pages may be presented on acomputer display (e.g., of receiver 102, gateway 104, user communicationdevice 105, or workstation 22, etc.) including the status of theinvitations (e.g., whether invitation pending, denied, or accepted).These one or more pages may be configured to allow changes to the rulesassociated with the remote monitors 114A-114M. For example, changes maybe made to the rules used to trigger notification messages, thedesignation of primary monitors (including time and locationdesignations), the designation of secondary monitors (including time andlocation designations), the escalation sequence and escalation thresholdsettings, and the like. In addition, the page(s) may provide a list ofremote monitors from which a user can designate primary and secondaryremote monitors and send invitations to any selected monitors. Thepage(s) may allow configuration of permissions, such as whether a remotemonitor 114 is authorized to receive one or more of notificationmessages, authorized to view patient data (e.g., sensor data includingcurrent and/or past data), and the like.

FIG. 12 depicts an example invitation page 500 presented at a remotemonitor 114 in the form of an email message. In this example, a user,“John Doe,” associated with a sensor system 8 and receiver 102 hasinvited remote monitor 114 to be a monitor as indicated by theinvitation at 502. Moreover, the invitation may include instructions forthe remoter monitor, which in this example includes clicking on a linkat 504 to allow a download of the remote monitor application code fromsecure server 110 or another server (e.g., iTunes server operated byApple, Inc.) and accepting the invite at 506 (which sends an acceptancemessage to secure server 110). The remote monitor may also be given theoption to not accept the invitation to monitor by selecting auser-selectable decline icon 508, which may notify secure server 110 ofthe decline indication.

In some implementations, to register an invited remote monitor 114 withthe secure server 110, the remote monitor and the receiver 102 may eachinput a value, such as a code, a shared secret, a link (e.g., a uniformresource locator), a password, or a combination thereof, to allowconnection establishment and thus enabling remote monitor 114 to receivenotification messages for events associated with receiver 102 and tohave access to sensor data and reports at secure server 110. Moreover, auser, such as host 199, may access an Internet browser using workstation22 of FIG. 1, for example, to access secure server 110 and login to viewand manage the one or more devices granted remote monitoring privileges.

Connection establishment refers to the process of adding one or moreremote monitors to system 100 to provide a second layer of oversightinto the operation of sensor system 8 and receiver 102. The connectionsto the remote monitor 114 may be established based on an invitation sentto the remote monitor 114. This invitation may be sent with the consentof the receiver 102, gateway 104 (e.g., via a user interface therein),and/or host 199. For example, the receiver 102 and remote monitor 114may be required to both accept invitations or to enter a code (e.g., apassword, shared secret, and the like) in order to opt in to the remotemonitoring provided at system 100.

In some example implementations, one or more of the devices of remotemonitoring system 100 (e.g., remote monitor 114, receiver 102, gateway104, user communication device 105, or workstation 22) may need a code,such a prescription code provided by a health care provider, in order toregister with secure server 110. The code may expire after apredetermined time and/or may be limited to a predetermined number ofuses (e.g., a single use code that can be used once to register withsecure server 110 to obtain a remote monitor code). Furthermore, thecode may also define at the server 110 a configuration for the devicebeing registered as a remote monitor 114, such as permissions (e.g.,whether can receive notifications, view past sensor data and/or viewcurrent sensor data) of and/or alert settings associated with the remotemonitor.

In some example implementations, the secure server 110 may haveconfiguration information defining the identity of the receiver 102 andremote monitor 114, so that a user, such as host 199, may access secureserver 110 and then add one or more devices, such as receiver 102 andremote monitor 114 to the user's system. The remote monitor 114 mayquery secure server 110 to obtain information regarding which hosts (orreceivers) the remote monitor is allowed to monitor and the secureserver can configure the remote monitor 114 accordingly. In some exampleimplementations, the notification messages sent to the remote monitor(s)may be configured to suit the needs of a given remote monitor-user andthese needs may be different from the needs of the host-patient.Accordingly, the rules dictating the sending of a notification messageto remote monitor 114 may be different from a rule used to trigger analert to the receiver 102 being used by the host-patient.

The following provides an illustrative example of a caregiver usingremote monitor 114 as part of host-patient care with reference to FIG.2A. Specifically, the caregiver may be administering an analyte therapyto the host-patient. For example, the caregiver may be a parent of ayoung child. In this example, a parent may want to receive notificationmessages, which are identical to the alerts, sent to the receiver 102(or triggered by the receiver) and host-patient (which in this exampleis a child). Moreover, the secure server 110 may obtain the receiver 102settings through the gateway 104. During the configuration of the remotemonitor 114, the secure server 110 may prompt the parent to select a setof rules that are identical to those being used by the child's receiver.In this example, any subsequent changes made to the set of rules beingused for the child's receiver would be programmatically propagated tothe set of rules being used to send notifications to the parent's remotemonitor 114. Although the previous example described the same set ofrules being used from the host and monitor, the host and monitor mayimplement different rules as well.

The following provides another illustrative example of a host-patientadministering treatment but in this case, the host-patient or caregivermay not want a high degree of oversight of the host-patient. To thatend, the caregiver at remote monitor 114 may want the host-patient toreceive an alert first, but allow the patient-host time to act on thealert to correct or acknowledge the event prior to an alert being sentto the caregiver. As an example, an alert triggered by the receiver 102may indicate a hypoglycemic or hyperglycemic event, and if after acertain period of time the host-patient has not taken one or morepredetermined action(s) to remediate the event (as evident by subsequentglucose measurement indicating the same or worsening patient state, forexample), the caregiver at remote monitor 114 may receive a notificationmessage responsive to the event. That is, if a patient-host usingreceiver 102 does not respond or acknowledge an alert in a predeterminedmanner, the caregiver at remote monitor 114 may then receive anotification message. The caregiver at remote monitor 114 may thusreceive a notification message when the host patient at receiver 102fails to respond to, or acknowledge, certain, real time events, such asa low glucose event (which may be considered severe as the host-patientmay be incapacitated or unaware of the event so a notification to theremote monitor is in order). However, the secure server 110 eitherdelays sending reminders or stops sending reminders responsive to anotification message if one or more predetermined occurrences areidentified by the secure server. The one or more predefined occurrencescan be curing the underlying event triggering the alert, acknowledgingthe alert or taking a defined action, such as administering insulin andthe like.

Further, the secure server 110 may be configured with a delay to waitfor an acknowledgement or action before notifying the remote monitor114, and this delay may vary based on the type and/or severity of thecondition causing the alarm, and vary depending upon default or userconfigured settings of the remote monitor. In addition, the secureserver 110 may be configured to also monitor data from the receiver 102even after an acknowledgement message is received from the receiver 102in response to an alert. For example, the secure server 110 may receivethe acknowledgement message (which may be a message sent by receiver102), but secure server 110 may wait a predetermined time for sensordata from the receiver 102 confirming that the host-patient has indeedtaken action. Again, this delay may vary based on the type and/orseverity of the condition causing the alarm.

The following provides yet another illustrative example of ahost-patient administering treatment but in this case, the host-patientis highly independent so the remote monitor may only be triggered in anemergency. For example, the secure server 110 may include a rule totrigger a remote monitor in the case of an emergency, such as a severehypoglycemia event occurring at night. In this scenario, thehost-patient may not be able to respond to the alert of the event, sothe secure server 110 may trigger a notification message if the glucosefalls to an extremely low level for a period of time or the user doesnot respond after a period of time to the very low glucose alert sent toreceiver 102. And, the period of time may be varied based on the typeand/or severity of the condition causing the alarm.

The following provides another illustrative example of a host-patientthat is highly independent but is hypoglycemia unaware and has notrusted sources for emergency response. In this use case, thehost-patient may select a remote monitor 114 associated with anemergency medical service so as to automatically notify the service inthe event of a severe hypoglycemic event when the glucose falls to anextremely low level for a period of time or the user does not respondafter a period of time to the very low glucose triggered by receiver102.

Managing Remote Monitor Alert Settings

In some example implementations, a user may manage the alerts for eachof remote monitors 114A-114M monitoring a host 199. For example, thehost 199 can use host monitoring system 198A to invite remote monitor114A to be a monitor and configure the permissions at secure server 114using receiver 102, gateway 104 (including host communication device),or workstation 22. The permission may be specific to one or more certainalerts or global in the sense that all the alerts for remote monitor114A may be manipulated by the user. Although the previous exampledescribes the permissions being set by a user, the permissions may bedetermined programmatically as well.

To manage alerts, a user may access secure server 110 using a computingdevice, such as remote monitor 114, receiver 102, gateway 104, hostcommunication device 105 or workstation 22, and manage the alerts by forexample setting alerts, changing thresholds, turning alerts on or off,and the like. FIG. 13 depicts an example page 600 that may be presentedon a display of the host computing device. The page 600 may allowchanges to alerts for a certain remote monitor 114A. In the example ofFIG. 6, a low glucose alarm 602 may be turned on 610, and the threshold604 that defines the threshold configured by the user. FIG. 6 alsodepicts that delay 606 may be managed using page 600 as well. Forexample, the delay 606 may define how long the secure server 110 waitsbefore sending a notification message from the secure server (vianotification service) to the remote monitor 114A if the host's glucoseconcentration remains below the low threshold. In this example, thedelay is zero seconds, but can be changed using page 600 to be anotheramount of time, such as 5, 10, 15 or 30 minutes, or an hour. Page 600also allows secure server 110 and/or notification service 112 to triggersending reminders 612 and vary a time 606 associated with triggering thereminders. For example, the reminders represent the amount of time thatelapses before the secure server 110 triggers another notification toremote monitor 114A if remote monitor has not acknowledged the alert orif the host has not cured the event that originally triggered the alert.In this example, if a user fails to acknowledge an alert or takecorrective action within 30 minutes after an original notificationresponsive to a reading below 70 mg/dl, the secure server 110 sendsanother notification regarding the low glucose level to the remotemonitor 114A. Although the example described with respect to FIG. 6refers to a low glucose value, a delay, and a reminder, any other aspectof the alerts for a remote monitor 114 described elsewhere herein can belikewise managed as well, such as high glucose level alerts, high rateof change alerts and the like.

In addition, while the above description with respect to FIG. 6 refersto managing alerts for a remote monitor 114, a similar page can be usedby receiver 102, gateway 104 or host communication device 105 to managealerts triggered by host communication device in the implementations ofFIGS. 2A-2C. As an example, host communication device 105 can displaypage 600 for managing alerts by host communication device independentfrom receiver 102. In this way, host communication device 105 canfunction as a secondary alert device for host 199.

In some implementations, a user may modify one or more rules definingalerts representative of events associated with the analyte state of thehost. A user may use a computing device, such as remote monitor 114,receiver 102, gateway 104, host communication device 105, or workstation22, to modify the alert settings, such as low glucose level thresholdsand the like, of the host monitoring system 198. In this way, a parent,for example, can modify the settings of their child's remote monitoringsystem 198.

Although the previous example refers to modifying low glucose alarms,the modification may include varying a first threshold associated with alow level of glucose at the host, varying a second threshold associatedwith a high level of glucose at the host, varying a delay between whenthe message is triggered by the receiver 102, varying a time valuebetween when a reminder message is sent, and any other alert that may betriggered for a host monitoring system 198 or remote monitor 114.

Moreover, the secure server 110 may adapt the set of rules associatedwith a host 199. For example, the set of rules for a remote monitor 114monitoring host 199 may be predetermined based on some basichost-patient demographics. After initial use of remote monitoring system100, secure server 110 may programically adjust thresholds used totrigger some or all events. These adjustments may be made for a varietyof reasons. For example, thresholds, such as glucose levels, glucoserates of changes, and the like, used to determine when to trigger anevent may be adjusted to reduce the frequency of some alerts and/ornotifications as a remote monitor 114 receiving too many messages maydecide to ignore the messages. The thresholds may also be adjusted totighten the range of a patient's glucose variation during the day inorder to decrease the variability in a host's day-to-day glucosevariability.

In some example implementations, data management tools and CGM analysesmay be used to help patients better manage their diabetes or assistclinicians in enhancing recommendations. As glucose data (and/or otheranalyte data) may be provided to secure server 110 in about real time,the data may be used by case managers in payer systems and/or medicalsystems to enhance ongoing diabetes management. However, it may beimpractical for a diabetes case manager to review the resultingso-called “big data.” As such, filters may be used to allow exceptionbased reporting of use or glycemic patterns to promote efficient use ofthe case manager's time by identifying specific issues. To that end, oneor more patterns may be defined at the secure server to identify theissues requiring the attention of the case manager. The patterns mayinclude longitudinal analysis or comparisons between time periods. Thesepatterns may also identify high-risk patients, such as those withfrequent or severe lows, frequent or severe highs, and/or marked glucosevariability. This may be considered particularly important for use withpatients on intensive insulin therapy, with hypoglycemia unawareness,poor control, those new to insulin, and the like. The patterns may alsoidentify therapy non-responders identifying, such as those withsustained hyperglycemia, suggesting non-response to therapy or worseningof control, suggesting non-adherence, disease progression, ortachyphylaxis. This may be considered particularly useful when newmedicaments are added or therapy is optimized. The patterns may alsoidentify responders or non-responders linked to diabetes education or byparticular providers or consultants.

In some example implementations, additional performance information maybe gathered at the secure server 110 from patients at a plurality oflocations. This additional information may be used to evaluateenvironmental factors that could influence and affect the sensor'sperformance. Rather than gathering and analyzing information solely froma single host-patient, data may be gathered at the secure server andthen compared on a macro level spanning across a plurality of hostpatients and/or across a plurality of geographic locations (or regions).In essence, the sensor system's 8 overall effectiveness may be evaluatedbased upon various environmental factors being monitored. For example,data gathered in real time from across the United States or even theWorld may show if temperature, humidity, altitude, or the like influencethe sensor system's 8 performance and thus provide an indication as towhether the sensor system 8 and/or sensor 10 should be replaced orrepaired. Moreover, the secure server 110 may also process receivedsensor information and identify patterns (e.g., by lot number, region,or the like), and additional algorithms, calibration information orfail-safes may be uploaded based on these identified patterns to improvethe sensor accuracy and/or performance.

In some example implementations, the secure server 110 mayprogrammatically track product performance and utilization of a sensorsystem including sensor 8 and/or receiver 102. For example, the sensorsystem and/or receiver may programmatically provide to secure server 110information identifying the sensor (e.g., lot number) and summarizingits performance. The performance metrics may include accuracy, on time,data capture, and the like. Moreover, if one or more sensor performancemetrics fall outside of an expected range, then secure server 110 mayrequest additional information to be transmitted from the sensorsystem/receiver to the secure server to allow classification of thefailure mode. For example, the secure server 110 may send alerts and/ornotifications to receiver 102, gateway 104 and/or remote monitor 114that the sensor system 8 and/or receiver 102 needs to be maintained(e.g., replaced, repaired, calibrated, and the like) based on determinedperformance information. And, the secure server 110 may also beconfigured to send, based on the performance information, alerts ornotification messages indicating that the sensors requires a reset, anew calibration value is needed, or a new sensor should be ordered. Thedata provided to the secure server 110 may be configurable and stored ata repository coupled to the secure server 110.

Moreover, sensor system tracking by the secure server may includetracking the performance of the receiver's wireless interface. Forexample, if a hardware error (or any detected error condition) occurs,information related to the error may be transmitted to the secure server110. The data transmitted may also be used to track feature utilization,which may include alert settings, number of screen visits, and the like.In addition, this data may be used to collect and manage data duringclinical studies. Furthermore, the sensor data transmitted to the secureserver 110 may also be expanded to tracking of patient performance ofglycemic control. When this is the case, performance metrics may includethe “time spent” in different glucose ranges, amplitudes of glycemicexcursions, insulin dose information, and the like. For example, duringa continuous glucose monitoring (CGM) session, data may be automaticallytransmitted to a secure server 110 and/or a coupled repositoryaccessible to the host-patient and/or the patient's clinical careprovider. Accordingly, the above-noted automatic tracking of productperformance and classification of failure modes may, in some exampleimplementations, provide more accurate information regarding productperformance, facilitate resolving sensor issues experienced by patients,and automate product replacement (or shipment) when the sensorperformance is deemed ready for replacement.

In some example implementations, the secure server 110 may provide aclosed control loop. Specifically, secure server 110 may send a messageto receiver 102, which responds to secure server 110. Moreover, secureserver 110 may send messages to remote monitor 114, which responds tosecure server 110. Accordingly, secure server 110 may request an actionfrom receiver 102 and/or remote monitor 114, and receive acknowledgementfrom receiver 102 and/or remote monitor 114, when the action iscompleted, forming thus a closed loop. The receiver 102 may include oneor more aspects of the functions provided by the remote monitor 114, andremote monitor 114 may include one or more aspects of the functionsprovided by the receiver 102.

Example Host Monitoring System Set-Up Process 1000

FIG. 10 is a flow chart depicting process 1000 for setting up hostmonitoring system 198 in accordance with some implementations. Forillustrative purposes, the setup process 1000 will be discussed withreference to the remote monitoring system architecture illustrated inFIG. 2C, although it is understood that setup process 1000 can beapplied to the architecture of FIG. 2A or FIG. 2B with changes toaccommodate the differences of architectures.

Additionally, for further ease of understanding, the followingcomponents of FIG. 2C are used in one example of process 1000: thesensor system 8 and receiver 102 make comprise a DexCom G4 Platinumcontinuous monitoring system, available from DexCom, Inc., where thesensor 10 is a DexCom G4 Platinum sensor, the sensor electronics module12 is a DexCom G4 Platinum transmitter, and the receiver is the DexComG4 Platinum receiver; the receiver 102 is docked in the docking station103 as illustrated and discussed with reference to FIG. 7B; the hostcommunication device 105 comprises an Apple iPhone available from Apple,Inc.; and each remote monitor 114A-114M comprises an Apple iPhone orother mobile phone having an iOS® (commercially manufactured by Apple,Inc.), Android® (commercially manufactured by Google, Inc.) or Windows®(manufactured by Microsoft, Inc.) based mobile operating system.

At block 1000, a user downloads a host monitoring application on to thehost communication device 105. (It is understood he host monitoringapplication can be downloaded onto gateway 104 in the implementation ofFIG. 2A or downloaded onto receiver 102 in the implementation of FIG. 2Bthe host monitoring application can be, for example.) In someimplementations, the host monitoring application is downloaded from aserver, which can be independent (e.g., operated by a different entity)of secure server 110, such as the Apple App Store server operated byApple, Inc. However, in some implementations, the host monitoringapplication is downloaded from server 110. The host monitoringapplication can comprise instructions for the host communication device105 to perform the host communication device functions described herein,such as gathering sensor data from the receiver 102 via the dockingstation 103, transmit the sensor data to the secure server 110, managealerts of host monitoring system 198, inviting users to become remotemonitors of host, manage remote monitor settings, pairing with thedocking station 103 and/or receiver 102, and the like.

Once the host monitoring application is downloaded to the hostcommunication device 105, a user can open the application (e.g., byselecting an icon associated with the host monitoring application on ahome screen of the host communication device) and use the application tocreate an account at block 1012. In addition to storing accountinformation on the host communication device 105, the account is createdand stored on secure server 110. In some implementations, creating theaccount includes entering user identifying information, such as name andemail address, a password, and a unique identifier associated with thereceiver 102, such as the receiver's serial number, or the sensor system18, such as the serial number of sensor electronics 12. As discussedbelow in block 1016, the receiver's serial number or sensor electronics'serial number can be used for pairing the receiver 102 and/or dockingstation 103 with the host communication device 105, as well as otherfunctions.

FIG. 9 illustrates an exemplary page 900 host monitoring application candisplay to a user at the account setup block 1012 to facilitate entry ofa unique identifier, such as the serial number of the receiver 102, theserial number of the sensor electronics 12 or other identifierassociated with host monitoring system 198. Here, the page 900 is anillustration of the location of the serial number to aid the user infinding the serial number of entry, which is a serial number on receiver102 in this example. Page 900 also provides an alphanumeric entry fieldthe user can select to manually enter the serial number. In addition,page 900 provides selectable icons 902 and 904 that allow the user totake a photo of the serial number using a camera of the hostcommunication device 105 and scan in the serial number using a bar codescanner of the host communication device 105, respectively, for entry ofthe serial number.

At block 1014, the user uses the host monitoring application to managealert settings for the host communication device 105. The hostapplication can initially present default alert settings, where the usercan modify the default user settings using the user interface of thehost communication device 105. In some implementations, the alertsettings comprise repeating one or more alerts on the receiver 102. Thisway, the host communication device 105 can amplify (e.g., trigger adifferent type of alarm than the receiver, such as a louder alarm)and/or echo alarms of the receiver (e.g., only sounding the alarm aftera predetermined amount of time from the alarm of the receiver if theevent triggering the alert on the receiver has not been cured). Thealert settings can also include turning off or on alerts for variousevents.

The user pairs the host communication device 105 with the dockingstation 103 at block 1016. In some implementations, to pair the hostcommunication device 105 with the docking station 103, the user powerson the docking station and connects the receiver 102 to the dockingstation. At this point, the host communication device 105 and thedocking station 103 begin a pairing and authentication procedure.

In some implementations, the docking station 103 does not have a displayand thus conventional pairing and authentication procedures may not beadequate. Thus in some implementations, receiver 102 provides a serialnumber stored in memory of the receiver to the docking station 103 and auser enters the receiver serial number into the host communicationdevice 105. The serial number stored in memory of the receiver 102 canbe stored during manufacturing of the receiver. The host communicationdevice 105 can then transmit the serial number (or encrypted version ofthe serial number) to the docking station to establish an authenticatedcommunication channel.

The following pairing and authentication procedure may be used in someimplementations. In response to the receiver 102 being docked to thedocking station 103, the docking station derives an authentication tokenfrom the receiver's serial number (which the receiver transmits to thedocking station automatically upon docking) and puts it in a GenericAttribute Profile (GATT) characteristic. The docking station 103 thenbroadcasts a general advertisement to bond. The host communicationdevice 105 device looks for the advertisement. After discovering thedocking station 103, the host communication device 105 connects andperforms a service discovery. The host communication device 105 thenattempts to read the GATT characteristic mentioned previously. Thedocking station 103 responds with an insufficient authorization message(pairing and encryption is required). The host communication device 105then prompts the user to pair with the docking station 103. Both thedocking station 103 and the host communication device 105 compromise along term key to use for encryption and are then paired. The hostcommunication device 105 then reads the token from the characteristicmentioned above, and using this characteristic, verifies theauthenticity of the docking station 103. The host communication device105, which has previously derived its own token from the receiver serialnumber entered previously into the host communication device in block1012, writes this token to a GATT characteristic in the docking station103. The docking station 103 then uses this token to verify theauthenticity of the host communication device and, if authentic, entersa persistent bonded state.

In some implementations, using the above-mentioned pairing andauthentication process, if the two devices (receiver 102 and dockingstation 103) are disconnected at any point, the docking station 103directs an advertisement for connection.

It should also be understood that paring process 1016 is described withrespect to receiver 102 and docking station 103 as exemplary only. Oneor more steps in process 1016 can be omitted or modified to allow thepairing process 1016 to work between other components, such as receiver102 and gateway 104 of FIG. 2A.

At block 1018, the user uses the application on the host device 105 toinvite remote monitors 114. Here, the application may prompt the userfor identifying information of a potential user of a remote monitor,including a name and email address accessible from a device capable ofbeing a remote monitor 114, such as a mobile smart phone or tabletcomputer. In addition, the application can prompt the user forpermissions that the user wants the remote monitor 114 to have, such aspermission to view trend graph data, and alert settings that the userwants the remote monitor 114 to have. Once finished, the applicationsends an invitation to the remote monitor 114, with the information inthe invitation, such as identifying information, permissions and alertsettings stored on secure sever 110. The user can invite additionalremote monitors using the above described invitation procedure. In someimplementations, the application can include a page that lists thestatus of all invitations sent by the user.

Note that process 1000 can be implemented using a setup wizardimplemented by the host monitoring application on host monitoring device105 to guide the user through the setup process 1000.

Further, in some implementations where a serial number or other numberassociated with a component is used as a unique identifier, the serialnumber can be printed or otherwise provided on the component usinginvisible ink. As used herein, invisible ink means a material that canbe printed on a surface that is invisible to the human eye, but can beoptically detected using a computing device, such as a smart phoneemploying optical detection using the smart phone's camera. A user canthen use a device having optical recognition capabilities, such as asmart phone, to take a picture of the component and the device canautomatically recognize the serial number and use the serial number forany of the functions described herein associated with using a uniqueidentifier. In this way, the serial number is not apparent to otherpeople, providing discretion and security.

Further, in some implementations where invisible ink is not utilized, itmay be desirable to place the unique identifier on a portion of thesystem that is hidden from the user when the system is in use, such ason the bottom of sensor electronics 12, so that the serial number isalso not viewable from a third party. This can also result in difficultyfor the user should the user need the serial number while the system 198is in use. Using invisible ink in the above-described manner, however,can solve this problem: the serial number need not be placed on aninaccessible portion of the system 198 because others will not be ableto view the number.

Example of Remote Monitor Set-Up Process 1600

FIG. 16 is a flowchart of an exemplary process of remote monitoringusing remote monitor 114. Similar to process 1000, FIG. 16 will bedescribed for illustrative purposes only with respect to the remotemonitoring system 100 architecture of FIG. 2C.

At block 1610, a user receives on a computing device, such as a smartmobile phone, an invitation to become a remote monitor. An exampleinvitation is illustrated and discussed in more detail with respect toFIG. 12. In some implementations, a user receiving the invitation caneither accept or deny the invitation by selecting an accept icon or denyicon, respectively, in the email. Denying the invitation ends process1600, whereas accepting the invitation moves process 1600 to block 1620.

At block 1620, the invitation programically directs the user via theuser's computing device to download a remote monitoring application, ifthe user accepts the invitation. In some implementations, accepting theinvitation at block 1610 programically triggers the user's computingdevice to automatically access a server carrying the remote monitoringapplication. The server can be the App Store operated by Apple, Inc. inthe case that the user's device is an Apple mobile device. The user thendownloads the remote monitoring application onto the computing device.

Note that in some implementations, the user of the remote monitor 114need not register with secure server 110, as in certain implementationsthe secure server already has the user's account information from whenthe invitation was formed in block 1012 of process 1000 (FIG. 10).

At block 1630, the user manages alert settings using the remotemonitoring application downloaded on the computing device (nowconsidered a remote monitor 114). The alert settings can initially beset at recommended alert settings set by the person that sent theinvitation at step 1012 in process 1000 (or default settings in the casethe person sending the invitation did not enter any recommendedsettings) in some implementations. The user of the remote monitor 114can then modify any of the recommended or default settings. The settingscan include setting threshold values for when to trigger an alert to theremote monitor, delays, reminders and no data alert settings, discussedin more detail elsewhere herein. The remote monitor 114 may thentransmit the settings of the remote monitor to the secure store forstorage and use when triggering alerts associated with the remotemonitor.

At block 1640, the remote monitor 114 monitors hosts' analyte levels aspermitted. The monitoring can include monitoring a plurality of hostsusing the remote monitor, as discussed in more detail with respect toFIG. 1. The monitoring can include receiving notifications triggered bysecure server 110 and sent via notification service 112 and viewingsensor data accessible from secure server. For example, in someimplementations, a user can activate the remote monitoring applicationon remote monitor 114 to view a dashboard page of a plurality of host'sglucose levels.

Example Invitation to Become Remote Monitor

As discussed above in block 1610 of FIG. 16, a user can receive aninvitation to remotely monitor host 199. In some implementations, theinvitation is the form of an email, such as that depicted in FIG. 12.The user can accept or deny the invitation using the email. The user canaccept the invitation by indicating that the user wants to install theremote monitoring application by selecting selectable text 504, or denythe invitation by selecting selectable text 508. If the user denies theinvitation, then the remote monitoring system 100 can notify the hostthat sent the invitation of the denial by sending a notification viaserver 110 and/or notification service 112 to communication device 105,for example. However, if the user accepts the invitation, then theremote monitoring system 100 can notify the host of the acceptance bysending a notification via server 110 and/or notification service 112 tocommunication device 105, for example, and process 1600 continues toblock 1620.

In some implementations, a receipt accepting the invitationautomatically sets up a remote monitoring account on server 110. Thatis, the recipient need not log in and create an account, as the hostprovided account creation information (recipient name, email, phonenumber and the like) for the recipient when generating the invitation.Further, the host can include a picture of the host during theinvitation creation process so that the invitation includes a picture ofthe host in the invitation sent to the recipient (which can help therecipient know the invitation is valid) and the picture of the host canbe used as the picture of the host in the remote monitor (such as on adashboard as discussed with reference to FIGS. 18A and 18B andelsewhere).

The invitation can include a single use token which the recipient of theinvitation can use to accept the invitation without requiring therecipient to log into the remote monitoring system, in someimplementations. The token can be in the form of a Globally UniqueIdentifier (GUID). The invitation may also include a timestamp of whenthe invitation was sent and when the invitations expires.

System Status View

In some implementations, a user of remote monitoring system 100 may notreadily know if the remote monitoring system 100 is working or why thesystem may not be working. For example, in the implementation of FIG.2B, a host 199 may not realize that data is not being transmitted fromthe sensor system 8 to the server 110, or even if the host realizes thatdata is not being transmitted, the host my not recognize where theproblem lies so that data transmission can resume. Accordingly, someembodiments provide a system status page to help a user identify if thesystem is working correctly, and, if not, what the source of the problemmay be.

FIGS. 11A and 11B are exemplary views of a status page 1100 inaccordance with some implementations. Status page 1100 includes a statusbar 1110 that includes representations of various components of remotemonitoring system 100. In this example, components of the system 100include a docking station 1114, a host communication device 1118 and aserver 1112. Communication channels between each of the componentsbetween components of system 100 are also included in FIGS. 11A and 11B,such as a first communication channel 1116 (e.g. Bluetooth®) between thedocking station 1114 and the host communication device 1118, and asecond communication channel 1120 (e.g. Wi-Fi or cellular) between thehost communication device 1118 and the server 1122. The status bar 1110can indicate components and communication channels that are determinedto be working and not working. For example, if a connection isdetermined to be working, then the connection can be graphicallydisplayed in a first state, and if the connection is not working thenthe connection can be graphically displayed in a second, differentstate. The first state and the second state can be depicted differently,for example, using color (e.g., green if in the first state, red if inthe second state), and/or graphics (e.g. a solid line if in the firststate and a broken line if in the second state) and the like. Further,each portion of the status bar, 1114, 1116, 1118, 1120 and 1122 can beuser selectable, where if a user selects a particular portion, the hostmonitoring application can display help information (in the form of apop-up message or new display screen, for example) that can help a userresolve issues associated with the portion selected by the user. Forinstance, if the docking station icon 1114 is in the second state andthe user selects the docking station icon, the remote monitoringapplication can display a message prompting the user to make sure thedocking station is plugged in to a power supply. Further, the remotemonitoring application can display a message prompting the user toensure the host monitoring device has Bluetooth connectivity enabled,for example, if the first communication channel is in the second stateand the user selects the first communication channel.

Status page 1100 can also include a character icon 1132 that displays anoverall status of the system. In the example of FIGS. 11A and 11B, thecharacter icon 1132 is in the form of a monster holding a sign. Theappearance of the character icon 1132 can change based on the status ofthe system so a user can quickly determine the status by viewing thecharacter icon. For instance, character icon 1132 can have a smilingexpression and holding a sign with a check mark to indicate the systemis working and transmitting sensor data, as illustrated in FIG. 11A. Incontrast, the character icon 1132 can have a frowning expression andholding a sign with an X to indicate the system is not working, asillustrated in FIG. 11B. The color of the character icon 1132 can alsovary depending upon the status of the system, such as green when thesystem 100 determines the system is working (i.e. data is being sentfrom the host to the server 1110) and red when the system determines thesystem is not working.

The eyes of the character icon 1132 can also help indicate to a user ifthe system is working, such as the eyes blinking if host monitoringapplication is working, or the eyes not blinking if the eyes are notblinking. The blinking of the eyes can also correspond to thetransmission rate or each transmission between components of thesystems, such as the docking station 103 and the host communicationdevice (FIG. 2C) or receiver 102 and gateway 104 (FIG. 2A). In thismanner, the host monitoring application can allow a user to determine ifthe remote monitoring system is actively working (i.e. eyes will beblinking), as opposed to the remote monitoring application being frozenin a state indicating the system is working even though it is not. Itshould be understood that eyes blinking is but one exampleimplementation, and that other features indicating continuedtransmission between components of the system can be used in addition orinstead to the eyes blinking, such as the character icon walking,jiggling, jumping or the like.

Host monitoring application can also display a status tab 1124 on statuspage 1100 and any other pages displayed by host monitoring application,as illustrated in FIGS. 11A and 11B. Status tab can be part of a menuthat includes a plurality of different selectable tabs associated withdifferent display pages of the host monitoring application that, whenselected, display the associated display page The tabs in FIGS. 11A and11B additionally include a follower tab, 1126, account tab 1128 and moretab 1130. Notably, the status tab can always display an indication ofthe connection state of the system, such being displayed in green andwith a check mark, as illustrated in FIG. 11A, if the system is working,or in red and with an X, as illustrated in FIG. 11B, if the system isnot working. The status tab can be displayed regardless of the currentpage being displayed, thereby providing the user with an indication ofthe status of the system regardless of the page being displayed.

In some implementations, host monitoring system 198 may be configured toperiodically send messages to server 110. If the server detects a lackof messages from the host monitoring system 198 for a predeterminedamount of time, then the server can trigger a notification to be sent tothe host monitoring system (such as receiver 102, gateway 104 or hostcommunication device 105) notifying the host of the lack of messages sothat the host can check to determine if the host monitoring system isworking, using for example status page 1100.

Host Monitoring Control Pages

Host monitoring application can also include various display pages thatallow the user to view statuses of remote monitors 114 and configurepermissions and settings associated with remote monitors.

FIG. 14 illustrates an overview page 1400 in accordance with someimplementations. Overview page can include a plurality of cells 1402a-1402 e, each cell associated with a remote monitor or potential remotemonitor. Each cell can include a name 1410 a-1410 e associated with theremote monitor for identification purposes. The cells 1402 a-1402 e canalso be displayed according to a status of the remote monitor. Forexample, cell 1402 a is grouped under a removed by remote monitor(referred to as a follower in FIG. 14) status 1404 a, cell 1402 b isgrouped under an expired invitation status 1404 b, cell 1402 c isgrouped under an active status 1404 c, cell 1402 d is grouped under aninvited status 1404 d, and cell 1402 e is grouped under a not sharingstatus 1404 e. Note that a plurality of cells can be displayed undereach group; FIG. 14 merely illustrates one cell per grouping for ease ofexplanation of the different groupings.

Page 1400 also includes a selectable help icon 1406 a-1406 e associatedwith each group status. By selecting a help icon, the host monitoringapplication can provide further information to a user that explains whatthe associated status involves. The help information can be displayed ina pop-up window for example.

Icons can also be displayed in a cell that illustrate permissions and/orenabled functions associated with that remote monitor. For instance,icons 1412 and 1414 indicate that remote monitor associated with cell1402 c has notifications enabled and has permission to view trend graphinformation associated with the host being monitored, respectively. Incontrast, if a remote monitor does not have permission for a particularfunction, like viewing a trend graph of a host, then the correspondingicon can either not be displayed in the cell or a different iconindicating the lack of permission can be provided instead.

Selectable tabs can also be provided in each cell. For example, FIG. 14illustrates removal tabs 1408 a and 1408 b that remove the cell from thepage when selected by a user. Arrow tabs 1416 c-1416 e can be used toprovide further information about the remote monitor associated withthat cell. For example, selecting a selectable arrow 1416 can cause thehost monitoring application to transition to settings display page thatprovides more detail about the associated remote monitor and the remotemonitor's settings.

An exemplary settings display page 1500 is illustrated in FIG. 15 inaccordance with some implementations. Settings display page 1500 caninclude identification information, such as a name 1502 and emailaddress 1504 associated with the remote monitor, permissions of theremote monitor and notification settings of the remote monitor. In theexample of FIG. 15, the permissions can include a trend graph permission1504 tab that a user can use to toggle between allowing and denyingpermission to view the graph. If permitted, remote monitoring system 100allows that remote monitor to view trend graph information of the host199 and, if denied, then the remote monitor cannot view the trend graphinformation of the host. Notification settings allow the user of hostmonitoring application to view the current notification settings of theassociated remote monitor. The notification settings can include anurgent low notification alert 1506, a low notification alert 1508, ahigh notification alert 1509 and a no data notification alert 1510, andeach alerts associated status (e.g., associated threshold values andwhether the alert is off or on). In some implementations, a user usinghost monitoring application can modify the remote monitors' settingsusing page 1500, for example, but in other implementations some or allof the settings can only be modified by the remote monitor, as indicatedin FIG. 15.

Display page 1500 can also allow a user of the host monitoringapplication to pause and cancel capabilities of remote monitor 114Amonitoring the host 199. A pause/resume control button 1514 canselectably stop and re-start remote monitoring capabilities of theremote monitor, such as stopping and starting notifications being sentto the remote monitor and/or permission for the remote monitor to viewsensor data of the host. Such a function can be useful in instanceswhere a host does not always want a remote monitor to be monitoring thehost. A specific example can include a baby sitter as a remote monitor.It may be desirable for the baby sitter to have remote monitoringcapabilities when caring for a child being monitored by the hostmonitoring system, but stop the remote monitoring when the baby sitteris no longer caring for the child. This way, a new invitation need notbe sent to the baby sitter each time the baby sitter cares for the childin order to selectively control monitoring by the baby sitter.

A Delete Remote Monitor control button 1516 can be used to delete theremote monitor from the list of remote monitors that can monitor thehost. In contrast to the pause/resume control 1514, deleting a remotemonitor using the delete control 1516 would necessitate the host tore-invite the person to become a remote monitor in some implementations.As discussed elsewhere herein, remote monitoring system 100 may have apredefined limit to the number of remote monitors that can monitor ahost, thus it may be become necessary for the host to delete the remotemonitor so that the host can add another remote monitor in someimplementations.

In some implementations, remote monitoring system 100 sends anotification message to a remote monitor that has had its permissions orsettings changed, or has been paused, resumed or canceled by theassociated host system. This way, the remote monitor notified of thechange and is not relying on the previous configuration.

In addition, each of the pause, cancel, and resume functions may beconfigured globally across all remote monitors associated with the hostinstead of or in addition to individual monitors as described above. Inthe case of a global function, separate global pause, cancel and resumecontrol buttons can be provided on page 1400 (not illustrated in FIG.14), for example, where pressing the global control button implementsthe respective function globally across all remote monitors monitoringthe host.

Remote Monitoring Dashboard View

As discussed elsewhere herein, the remote monitor 114 can provide aso-called dashboard view of hosts it is monitoring implemented on remotemonitoring device. FIGS. 18A and 18B are two different implementationsof dashboard page 1800 in accordance with some implementations. Thedashboard 1800 can include a plurality of cells 1802 a-1802 d, eachassociated with a different host. Each cell 1802 can include identifiersof the host, such as a default name of the host and a picture of thehost 1804 a-1804 d provided in the invitation.

In the implementation of FIG. 18A, each cell lists a current status ofthe cell, such as a time 1812 a when the analyte value 1806 a currentlydisplayed in the cell was measured, a statement 1812 b whether the hostis using the remote monitoring system 100, a statement 1812 c whetherthe hosts host monitoring system is working, or a statement 1812 dindicating that the remote monitor has been paused, for example.

In the implementation of FIG. 18B, the cells 1802 can be grouped on page1800 according to the status of the cell, such as removed 1814 by thehost (referred to as Sharer in FIG. 18B), active 1818 (i.e., system isconnected and providing data of the associated host to the remotemonitor), disconnected 1824 (i.e. system is not connected, e.g., becausereceiver 102 is not in docking station 103 in the implementation of FIG.2B) and not sharing 1826 (i.e. the host has paused the remote monitor).Further, cells within a group can be ordered by severity of themonitored condition or other criteria, as discussed elsewhere herein.

Cells 1802 can also include an indication of the permissions and/orsettings of the remote monitor associated with that host. For example, atrend graph icon 1810 can indicate that the remote monitor haspermission to view a trend graph of sensor data of that host.

Referring again to FIG. 18B, cells 1802 that are in the active group1818 can also include information about the health condition beingmonitored. For example the cell 1802 can display the most currentanalyte concentration value 1806 a that was provided to remote monitorand an trend arrow 1808 a indicating a rate of change of the measuredanalyte. Further information can also be provided in the cell, such as atime 1812 a associated with the measurement of the displayed analyteconcentration or if data has not been received from the host monitoringsystem.

User selection of a cell 1802 can also cause the remote monitor displayto transition to another display page that provides additionalinformation about the host associated with that cell. For example, theremote monitor can transition to a trend graph display (FIG. 19)associated with that host or a settings page (FIG. 17) associated withthat host (the arrow “>” can indicate if more information is availablefor the cell.

Voice Integration

In some implementations, users of the remote monitoring system 100 caninteract with the system using voice-recognition. The interactions caninclude outputting a glucose value, inputting a calibration value,setting alarm criteria (e.g. changing an alarm profile, changing analarm threshold, turning off or on a particular alarm, and acknowledgingan alarm).

In some implementations, a person using remote monitor 114 can query themonitor using a voice recognition application running on the monitor fora host's glucose value. As a specific, non-limiting example, a usercould query the voice recognition application for a particular host'sglucose value by pressing a button on the monitor 114 and speaking:“Tell me Joe's current glucose level.” In response, the monitor can openthe remote monitoring application to find the host named Joe that themonitor is monitoring and Joe's current glucose level. The remotemonitor 114 can then audibly output and/or display the glucose level,such as “Joe's glucose level is 125.” In some implementations, theremote monitor 114 can also automatically bring up a particular view inresponse to the user querying for a glucose value, such as one of theviews displayed in FIGS. 18A, 18B and 19. If the view is associated witha particular individual, then the view can be of the individual aboutwhom the user was querying, such as trend graph view of FIG. 19associated with Joe in the above example.

Similarly, it should be understood that a host using a device of hostmonitoring system 198 can query the system for his or her own glucoselevel using one or more of the features described above, and that theabove example is not limited to only remote monitoring device 114.

Further, the remote monitoring system 100 (or one or more componentsthereof) can be configured to automatically provide voice feedback to auser. For example, receiver 102 or host monitor 114 can beuser-configured to automatically provide an audible alert to a userindicating a monitored analyte value and/or rate of change. In someimplementations, the voice feedback can be configured so a user canspecify whether voice feedback is enabled and, if enabled, under whatconditions voice feedback will be provided. The conditions can includeone or more of a time interval (e.g., every 5 minutes), or if aspecified analyte measurement threshold (e.g., analyte value or rate ofchange value) is crossed.

In some implementations, host monitoring system 198 can also enter acalibration value using voice recognition. Here, a user can direct thehost monitoring system 198 to enter a calibration value by pressing abutton on a device of the host monitoring system 198 (e.g. a button 124on receiver 102) and speak: “Enter calibration value of 108.” The hostmonitoring system 198 can then use the calibration value to calibratethe host monitoring system 198 as it would had a user inputted the valueby hand, for example.

Further, whether or not voice calibration is used to enter a calibrationvalue, host monitoring system 198 (e.g., more specifically receiver 102)can confirm to the user that the entered calibration value istrustworthy. For example, in a situation where an entered calibrationvalue is much different from a currently monitored analyte value, thesystem may notify the user that the calibration value may be in error.This notification can be an audible, verbal notification, such as“Please check the calibration value again”, and/or textual alert. Insuch a situation, the user may want to re-check the number inputted intothe monitoring system to ensure the user correctly entered, and/orobtained the calibration value. The check can be based on the hostmonitoring system determining a difference between the calibration valueand a currently measured value are within predetermined thresholds,where the difference can be an absolute difference or percentagedifference.

Trend Graph View

FIG. 19 is an exemplary page that provides a trend graph 1914 of ahost's monitored analyte concentration in accordance with someimplementations. The trend graph can display a trend line 1916 ofmeasured analyte concentrations, as well as low and high thresholds 1918and 1920 that are used for alerting either the remote monitor 114 or thehost monitoring system 198. The trend graph page can also include auser-selectable slider bar that allows a user to select different timeframes of sensor data to view, such as three, six, 12 and 24 hour views.A picture of the host 1904 and name of the host 1902 can also beprovided so that a remote monitor is not confused as to the individualbeing monitored in case the remote monitor is monitoring a plurality ofdifferent hosts.

In some implementations, the page of FIG. 19 can automatically bedisplayed when the remote monitoring application is initially openedresponsive to a user directly opening the application and/or a useropening a remote monitoring notification on remote monitor 114 sent byserver 110 or notification service 112, as discussed elsewhere wherein.To illustrate, when a notification is received by a remote monitor 114,the remote monitor may display the notification on a lock or homescreen. A user can select the notification (e.g. using a predefinedgesture), the recognition of which by the remote monitoring device 114causes the remote monitoring device to display the trend graph of thehost associated with the notification.

In some implementations, trend graph 1914 can automatically modify thescale of the graph based on one or more criteria. The criteria can be atime of day (e.g. morning, lunch-time, bed-time, night), a currentanalyte value being monitored (e.g. a glucose concentration beingmonitored and displayed on trend graph 1914), a current rate of changeof a measured analyte concentration being monitored, whether aparticular alarm and/or threshold has been triggered, such as ahypoglycemia-related or hyperglycemia-related alarm, and the like. Oneor both of the x-axis scale and y-axis scale of the trend graph 1914 canbe recalled.

To illustrate, an exemplary implementation can be that the trend graph1912 rescales when a low threshold is crossed—potentially indicating ahypoglycemia or near hypoglycemia condition in the host—the trend graph1914 can reduce a default y-axis scale of 400, as illustrated in FIG.19, to 200. The time scale can also be reduced from a present timescale, such as reducing the time scale from a 24 hour view to a 3 hour,or even from a 3 hour view to a one hour view. Modifying the scale canprovide better resolution to the viewer of trend graph 1914 of a problemzone. The graph can then automatically revert to the default scale (e.g.400) upon the satisfying of a condition, such as once the user's analyteconcentration comes back above a threshold that triggered the scalemodification, after a predetermined amount of time or the like.

Further, so that a user understands that the scale has been modified,the display can also provide an indication that the scale has beenmodified. For instance, in the example above, the indication can includeone of more of the screen flashing, changing color and providing atextual reason for the rescaling (e.g., “hypoglycemia thresholdexceeded”).

It should be understood that while the above-described features of trendgraph 1914 can be used on any computing device described herein,including a host's monitoring device and a remote monitor's monitoringdevice. Nothing herein should be construed as limiting the applicationof these features to a particular device or application.

Remote Monitor Settings Page

FIG. 17 is an implementation of a settings page 1700 displayed on remotemonitoring device 114 that can allow the remote monitor to configureremote monitoring settings of a host. Settings page can include apicture field that displays a picture of the host 1506 and a name fieldthat displays a name of the host, both of which can be modified by theremote monitor using the settings page 1700. In some implementations,the picture and/or name are at least initially provided by a host duringthe invitation process described above, but the remote monitoring systemallows a user of the remote monitor to later modify the picture and/orname. The settings page also includes settings for variousalert/notification settings, such as an urgent low alert 1706, low alert1714, high alert 1724 and not data alert 1736. The function of each ofthese alerts is discussed elsewhere herein. As illustrated in FIG. 17,the settings associated with each of these alerts can be modified, suchas turning the alert on or off, changing the threshold value(s)associated with each alert and changing an alert alarm (e.g. sound,volume, vibration, or tones) associated with each alert.

Automatic Detection of New Receivers and Registration

In some implementations, receivers 102 need to be associated with a host199 so that when glucose data is received by server 110, the data can beassociated with the host. Accordingly, remote monitoring system 100 canassign a receiver to a host. This can initially be done through thepairing process discussed above with respect to block 1016 of FIG. 10.If a host receives a new receiver, to make a friendly user experienceand prevent errors, the host monitoring application can see that adifferent serial number is being used, check with the server 110 to seeif this is a new receiver or if this receiver is already owned byanother host and asks the host via communication device 105 if this istheir receiver and allows them to take ownership or it gives them anerror telling them that it is already owned.

Accordingly, an exemplary detection of a new receiver process can be asfollows. First, the host communication device 105 if a new receiver isbeing used by validating with server if the receiver is owned by someoneelse (via comparison of receiver serial numbers to a database, forexample). If the server determines that no one else owns the receiver,then the host monitoring application asks if the user if he or she wantsto make that receiver theirs. If yes, then the receiver and the datafrom that receiver are associated with that host.

Connection Processing

FIG. 20 is a diagram illustrating an exemplary sequence of initialprocessing 2000 that can take place using remote monitoring system 100.FIG. 20 is described with respect to the system architecture of FIG. 2A,although it should be process 2000 can be modified to be used with othersystem architectures, including that of FIG. 2B or 2C, as would beapparent to one of ordinary skill in the art.

At 2002, receiver 102 sends a heartbeat message to gateway 104 totrigger first connection logic. In some implementations, connectionlogic can include triggering an application resident on a gateway 104 tobegin connection establishment. The application may have been shut downor in a sleep or background mode of operation, and the connection logicallows the application to initiate a connection. As an example,connection logic can initiate radio connection procedures for anapplication running in the background of a mobile device running Apple'siOS operating system.

Gateway 104 then requests 2004 and reads 2004 manufacturing data fromreceiver 102, and subsequently checks with server 110 regarding theassignment status of the receiver 102 based on the data read at 2004. Insome implementations, the manufacturing data is a unique identifierassociated with the receiver 102, such as the receiver's serial number.

Assuming the assignment status is valid at 2008, gateway 104 requestsand reads the latest analyte concentration value at 200 from receiver102 at 2012 and 2014, respectively. The gateway 104 also requests andreads the receiver system time at 2016 and 2018, respectively, andrequests and reads system UTC time from server 110 at 2020 and 2022,respectively. Any offset (e.g. due to system drift) between the receivertime and the UTC time can be stored in RAM of the gateway 104 to offsetanalyte concentration timestamps when uploading data to server 110.

Gateway 104 then notifies server 110 of a remote monitoring sessionstarting at 2024, and requests and syncs past data with the server 110to ensure no gaps in data. To this end, gateway 104 reads apredetermined number of past analyte concentration values (e.g. past 288values) stored at the receiver 102 at 2026 and 2028. The past analyteconcentration value data are stored at gateway 104 but not yet uploadedto server 110. Instead, gateway 104 requests that latest analyteconcentration value data from server 110 at 2030 and 2032. At 2034,gateway 104 uploads to server 110 only analyte concentration value datanot yet uploaded to the server 110 based on the latest analyteconcentration value data read at 2030 and 2032. Gateway 104 then marksall analyte concentration data stored locally as uploaded to the server.

FIG. 21 is an exemplary diagram of steady state processing 2100 ofremote monitoring system 100. Steady state processing 2100 can followinitial processing 2000 described with respect to FIG. 20. Also, likeFIG. 20, FIG. 21 is described with respect to the system architecture ofFIG. 2A, although it should be process 2000 can be modified to be usedwith other system architectures, including that of FIG. 2B or 2C, aswould be apparent to one of ordinary skill in the art.

During steady state processing 2100, each time a heartbeat message 2102is transmitted by receiver 102 and received by gateway 104, the gatewaychecks to see if it is time to request data from the receiver 102. Thegateway 104 uses the receiver 102 system time and the system time of thelast analyte concentration to determine if it has been more than apre-set amount of time, which may correspond to an analyte concentrationcollection time interval of host monitoring system 198 (e.g., 5 minutes)or other time (e.g., once every 4 seconds or once every minute). If pastthe pre-set time, gateway 104 performs processing to obtain getting thenext analyte concentration value data from the receiver 102 as follows.

The gateway 104 requests the latest analyte glucose value data and thecurrent system time from the receiver 102 at 2104 and 2106. If theanalyte concentration value data is valid at decision block 2108, theanalyte concentration value data is saved locally at gateway 104. Then,the analyte concentration value data is uploaded to the server 110 at2110 and a heartbeat counter is reset at 2112.

However, if the analyte concentration value data is not valid, theanalyte concentration value data is not saved locally and the heartbeatcounter is reset. A CheckSession call 2114 is made to the server 110 tokeep the current log in session active. The CheckSession call is made toavoid login authentication for temporary outages of data from thereceiver 102.

Loss of Data Alert

In some example implementations, the secure server 110 may include arule to automatically trigger a notification message or anothercommunication mechanism (e.g., a phone call, short message servicemessage, and the like) to a remote monitor 114 if data has not beenreceived from host monitoring system 198 associated with the remotemonitor for a predetermined amount of time. This way, a user of remotemonitor 114 can be aware that something may be wrong with hostmonitoring system 198 and attempt to contact the host.

Location-Based Alerts

In some example implementations, the secure server 110 may use thelocation of the receiver 102, gateway 104, host 199, and/or remotemonitor(s) 114 when determining whether to send a notification messageand/or determine destination of a notification message. For example,when a host being monitored is in a first location and travels to asecond location, the secure server 110 may, based on rules, select afirst remote monitor 114A near the first location and, when the hostmoves to the second location, select a second remote monitor 114Blocated near that second location. Location may also be used to varyalerts and notifications. For example, the secure server 110 may varythe rules used to trigger an alert or notification based on the host'slocation. Location may be used in combination with time as well, so thesecure server 110 may vary thresholds associated with alerts andnotifications based on location and/or time of day.

Acknowledgement Notifications

In some example implementations, the receiver 102 or gateway 104 maypresent a prompt (e.g., message, window, etc.) at a user interfacerequiring a host to acknowledge the triggered alert and/or indicate whatcorrective action was taken in response to the alert. The prompt mayinclude a prepopulated list of options that the user can select (e.g.,administered insulin, consumed carbohydrates, and the like) to indicatethe corrective action that was taken. A notification message may be sentdirectly to one or more remote monitors 114, or through the secureserver 110 and/or notification service 112, to the remote monitor(s), sothat the remote monitors are aware that the patient has acknowledged thealert and/or that corrective action taken (and/or a description of thecorrective action).

In addition, remote monitor 114 can allow a user to select from aplurality of pre-populated messages to send to host monitoring system. Auser can select the notification, whereupon the remote monitor displaysa list of pre-populated text messages that the user can select from tosend to the host monitoring system. The messages can be selected byremote monitor to be relevant to the underlying cause that triggered thenotification message. For instance, if the notification message wastriggered by a low glucose level of the host, then the messages can bestatements related to low glucose levels, such as “are you feelingokay?”, “should you drink some orange juice?”, and the like. Eachmessage can be user selectable, and when selected, cause the remotemonitor 114 to send the message to the host monitoring system fordisplay on the host monitoring system, either directly from remotemonitor to host system 198 or indirectly through the server 110, forexample. In addition, selection of the notification can automaticallydisplay a prompt to call the host, where user selection of the promptcauses the remote monitor 114 to dial the phone number associated withthe host (e.g. a smartphone that is part of the host monitoring system198).

Motivational Messages

In some example implementations, the alerts sent to the receiver 102and/or the notification messages may include motivational concepts. Forexample, if the host-patient has minimized the rate of change inglycemic levels, the secure server may send an alert to the receiver 102and/or a notification message to remote monitor 114 stating “Great jobmaintaining your therapy-keep it up!.” These motivational concepts maypositively motivate the users to stay on the therapy program. In someexample implementations, secure server 110 may include one or moreevents mapped to motivational concepts, so that triggering an eventcauses sending a message including the motivation concept to thereceiver 102 and/or a remote monitor 114.

In some example implementations, the secure server 110 may use patterns,as noted above, to predict aspects of the patient-host's treatment. Forexample, a pattern may detect a glycemic change at a given time of dayfrom a prior, established pattern, and then trigger a rule to send analert to the receiver 102 and a notification to the receiver 114stating, “Did you miss lunch?” These simple, non-technical querymessages may evoke a better response from the host-patient to maintain atherapy, when compared to only providing measured data or statistics toa host-patient or remote monitor. In some example implementations,secure server 110 may include one or more events mapped to simplemessages, so that triggering an event causes sending a message includingthe simple message to the receiver 102 and/or a remote monitor 114.

Audit Trail

The secure server 110 may also provide an audit trail. For example, thesecure server 110 may store information related to when notificationswere pushed to the remote monitor 114 using, for example, notificationservice 112, and when the remote monitor acknowledges the notification.The secure server 110 may also generate one or more reports to determinetimelines and/or identify the effectiveness of remote monitors 114(which can be used to select remote monitors and/or settings of system100, such as alert settings, to more effectively monitor host 199).

Timestamping

In some implementations, analyte levels provided to remote monitors 114may not be real-time. For example, while it may be desired to provideanalyte values to remote monitors in real time, there may be a timedelay between when the analyte value is measured by the analyte sensorsystem 8 and when the analyte level is provided to the remote monitor114 and/or secure server 110. The delay may be due to any of the sensorsystem 8 only transmitting values periodically to the receiver 102, thereceiver 102 transmitting only periodically values to gateway 104, thegateway having difficulty connecting to secure server 110, and secureserver having difficulty connecting to remote monitor 114, for example.Consequently, in some implementations, a glucose value transmitted tothe remote monitor 114 is displayed on the remote monitor with a timeindicating the time to which the analyte value that triggered thenotification corresponds (e.g., the analyte value that met or exceededthe threshold that triggered the notification). The time may be the timeof day the analyte value was measured (e.g., 2:10 p.m. Pacific StandardTime), or may be a difference in time since the analyte value wasmeasured (e.g., 2 minutes ago, 30 minutes ago, 4 hours ago, etc.).

In addition, due to a time delay, the secure server 110 may end upsending a notification to remote monitor 114 based on a time delayedanalyte value. In such a case, the notification can include a timeassociated with the alert that triggered the notification, such as“Mike's blood glucose went below 70 mg/dl at 2:10 P.S.T.” or “Mike'sblood glucose went below 70 mg/dl 25 minutes ago.” Further, because anotification may not be viewed right away on the remote monitoringdevice, the remote monitoring device 114 can automatically update anytime associated with the notification until the notification isacknowledged.

To accommodate for differences in time zones between a host and a remotemonitor, the remote monitoring system can use a universal time and thenconvert the universal time to the time zone of the remote monitor, inaccordance with some implementations. That is, a time stamp of a sensordata value generated by host monitoring system 198 and provided tosecure server 110 can be in Universal Standard time (UST) or GreenwichMean Time (GMT) and provided to the remote monitor 114 in the sameuniversal time, whereby the remote monitor converts the universal timeto the time zone in which the remote monitor is located as indicated bythe remote monitoring device.

In some implementations, due to difficulties with displaying time due totime lag and potential time zone differences between a host monitoringsystem 198 and remote monitor 114, which can cause confusion,notifications sent to remote monitor 114 do not display a time. Toremedy the lack of time indication, some implementations automaticallyopen the remote monitoring application on the remote monitor 114 anddisplay the user's monitored health information upon user acknowledgmentof the notification. The host's monitored health information that isinitially displayed upon opening the application can include indicationsof the host's current state, such as the most current analyte valueand/or a trend graph showing the past three hours of the host's measuredanalyte level, such as the trend graph page illustrated in FIG. 19.

Loss of Data Transmission

In some implementations, data may not be transmitted at times from thesensor system 8 to the secure server 110. Depending upon the system,this may be due to an unintentional lost data transmission connectionbetween one or more of sensor system 8 and receiver 102, receiver 102and gateway 104, docking station 103 and host communication device 105,or gateway 104 and secure server 110, for example. Or, the loss may beintentional, such as a user turning one or more of the components of theremote monitoring system 100 off, such as the receiver 102 or hostcommunication device 105. In any such instance, the secure server 110can be configured to automatically send a notification indicating theloss of data transmission to one or more of the host monitoring system198 and remote monitors 114A-114M upon detection of such a loss.

However, it may be desirable at times not to send such a loss of datatransmission notification so remote monitors 114 are not overlymessaged. As an example, a host being monitored may be sleeping at nightand get up to go to the kitchen for a drink of water. This can result ina loss of data transmission if the sensor system 8 is out of range fromthe receiver 102 resting on a nightstand of the host 199, for example.Consequently, a delay associated with loss of data transmission errorscan be implemented so that the server 110 initiates a loss of datanotification only if data is not received after a predetermined amountof time or after a predetermined number of attempted connection attemptswith host monitoring system 198.

Further, it may be desirable to not send loss of data notificationsevery time there is a loss of data transmission, even if the loss ofdata transmission is for an extended period of time. For example, in theimplementation of FIG. 2C, the docking station 103 may be stationary.Thus, a host may only be able to transmit health readings when the hosthas the receiver 102 docked in the docking station and the host is insufficient proximity to the receiver and docking station for datatransmission. However, a host may want to remove his or her receiver 102from the docking station 103 when the host leaves for work, for example.It may not be desirable to trigger a notification to remote monitors 114when the host removes the receiver from the docking station 103, as thismay not be considered an important enough event.

Accordingly, in some implementations, the remote monitoring system 100can determine that the receiver was removed from the docking station 103as opposed to, for some reason, the host monitoring system 198 notfunctioning correctly and not providing sensor data to the secureserver. In one implementation, the remote monitoring system 100determines that the receiver is not docked in the docking station 103 bymonitoring transmissions from the docking station. For instance,transmissions from the docking station 103 that include informationgenerated by the receiver 102 indicates that the receiver is docked andtransmissions from the docking station 103 that do not includeinformation generated by the receiver indicates that the receiver hasbeen removed from the docking station.

Eyewear Display Device

Although the above disclosure is primarily described with respect to useof a hand-held computing device, it should be understood that otherdevices can be used instead or in place of the smart phone. For example,in some implementations, sensor data are transmitted from the personalcomputing device to a computing device in the form of eyewear andmessages and information displayed on the eyewear for the user to view.An example of such eyewear is Google Glasses manufactured by Google,Inc. The user's eyewear interface can use a near-field radio link toreceive data, either directly from sensor system 8, or through anintermediary device, such as receiver 102 or gateway 104.

In some implementations, transmission of the data may be event-driven,for example, driven by the occurrence of a low or high glucoseexcursion, as discussed herein.

Various implementations of the subject matter described herein may berealized in digital electronic circuitry, integrated circuitry,specially designed ASICs (application specific integrated circuits),computer hardware, firmware, software, and/or combinations thereof. Thecircuitry may be affixed to a printed circuit board (PCB), or the like,and may take a variety of forms, as noted. These various implementationsmay include implementation in one or more computer programs that areexecutable and/or interpretable on a programmable system including atleast one programmable processor, which may be special or generalpurpose, coupled to receive data and instructions from, and to transmitdata and instructions to, a storage system, at least one input device,and at least one output device.

These computer programs (also known as programs, software, softwareapplications, or code) include machine instructions for a programmableprocessor, and may be implemented in a high-level procedural and/orobject-oriented programming language, and/or in assembly/machinelanguage. As used herein, the term “machine-readable medium” refers toany non-transitory computer program product, apparatus and/or device(e.g., magnetic discs, optical disks, memory, Programmable Logic Devices(PLDs)) used to provide machine instructions and/or data to aprogrammable processor, including a machine-readable medium thatreceives machine instructions.

To provide for interaction with a user, the subject matter describedherein may be implemented on a computer having a display device (e.g., aCRT (cathode ray tube) or LCD (liquid crystal display) monitor) fordisplaying information to the user and a keyboard and a pointing device(e.g., a mouse or a trackball) by which the user may provide input tothe computer. Other kinds of devices may be used to provide forinteraction with a user as well; for example, feedback provided to theuser may be any form of sensory feedback (e.g., visual feedback,auditory feedback, or tactile feedback); and input from the user may bereceived in any form, including acoustic, speech, or tactile input.

The subject matter described herein may be implemented in a computingsystem that includes a back-end component (e.g., as a data server), orthat includes a middleware component (e.g., an application server), orthat includes a front-end component (e.g., a client computer having agraphical user interface or a Web browser through which a user mayinteract with an implementation of the subject matter described herein),or any combination of such back-end, middleware, or front-endcomponents. The components of the system may be interconnected by anyform or medium of digital data communication (e.g., a communicationnetwork). Examples of communication networks include a local areanetwork (“LAN”), a wide area network (“WAN”), the public land mobilenetwork, satellite networks, and the Internet.

Although a few variations have been described in detail above, othermodifications are possible. For example, while the descriptions ofspecific implementations of the current subject matter discuss analyticapplications, the current subject matter is applicable to other types ofsoftware and data services access as well. Moreover, although the abovedescription refers to specific products, other products may be used aswell. In addition, the logic flows depicted in the accompanying figuresand described herein do not require the particular order shown, orsequential order, to achieve desirable results. Moreover, as used hereinthe term “set” includes zero or more items, and the phrase “based on”can be used interchangeably (unless otherwise noted) with the phrase“based on at least.” Other implementations may be within the scope ofthe following claims.

While the disclosure has been illustrated and described in detail in thedrawings and foregoing description, such illustration and descriptionare to be considered illustrative or exemplary and not restrictive. Thedisclosure is not limited to the disclosed embodiments. Variations tothe disclosed embodiments can be understood and effected by thoseskilled in the art in practicing the claimed disclosure, from a study ofthe drawings, the disclosure and the appended claims.

All references cited herein are incorporated herein by reference intheir entirety. To the extent publications and patents or patentapplications incorporated by reference contradict the disclosurecontained in the specification, the specification is intended tosupersede and/or take precedence over any such contradictory material.

Unless otherwise defined, all terms (including technical and scientificterms) are to be given their ordinary and customary meaning to a personof ordinary skill in the art, and are not to be limited to a special orcustomized meaning unless expressly so defined herein. It should benoted that the use of particular terminology when describing certainfeatures or aspects of the disclosure should not be taken to imply thatthe terminology is being re-defined herein to be restricted to includeany specific characteristics of the features or aspects of thedisclosure with which that terminology is associated. Terms and phrasesused in this application, and variations thereof, especially in theappended claims, unless otherwise expressly stated, should be construedas open ended as opposed to limiting. As examples of the foregoing, theterm ‘including’ should be read to mean ‘including, without limitation,’‘including but not limited to,’ or the like; the term ‘comprising’ asused herein is synonymous with ‘including,’ ‘containing,’ or‘characterized by,’ and is inclusive or open-ended and does not excludeadditional, unrecited elements or method steps; the term ‘having’ shouldbe interpreted as ‘having at least;’ the term ‘includes’ should beinterpreted as ‘includes but is not limited to;’ the term ‘example’ isused to provide exemplary instances of the item in discussion, not anexhaustive or limiting list thereof; adjectives such as ‘known’,‘normal’, ‘standard’, and terms of similar meaning should not beconstrued as limiting the item described to a given time period or to anitem available as of a given time, but instead should be read toencompass known, normal, or standard technologies that may be availableor known now or at any time in the future; and use of terms like‘preferably,’ ‘preferred,’ ‘desired,’ or ‘desirable,’ and words ofsimilar meaning should not be understood as implying that certainfeatures are critical, essential, or even important to the structure orfunction of the invention, but instead as merely intended to highlightalternative or additional features that may or may not be utilized in aparticular embodiment of the invention. Likewise, a group of itemslinked with the conjunction ‘and’ should not be read as requiring thateach and every one of those items be present in the grouping, but rathershould be read as ‘and/or’ unless expressly stated otherwise. Similarly,a group of items linked with the conjunction ‘or’ should not be read asrequiring mutual exclusivity among that group, but rather should be readas ‘and/or’ unless expressly stated otherwise.

Where a range of values is provided, it is understood that the upper andlower limit, and each intervening value between the upper and lowerlimit of the range is encompassed within the embodiments.

With respect to the use of substantially any plural and/or singularterms herein, those having skill in the art can translate from theplural to the singular and/or from the singular to the plural as isappropriate to the context and/or application. The varioussingular/plural permutations may be expressly set forth herein for sakeof clarity. The indefinite article “a” or “an” does not exclude aplurality. A single processor or other unit may fulfill the functions ofseveral items recited in the claims. The mere fact that certain measuresare recited in mutually different dependent claims does not indicatethat a combination of these measures cannot be used to advantage. Anyreference signs in the claims should not be construed as limiting thescope.

It will be further understood by those within the art that if a specificnumber of an introduced claim recitation is intended, such an intentwill be explicitly recited in the claim, and in the absence of suchrecitation no such intent is present. For example, as an aid tounderstanding, the following appended claims may contain usage of theintroductory phrases “at least one” and “one or more” to introduce claimrecitations. However, the use of such phrases should not be construed toimply that the introduction of a claim recitation by the indefinitearticles “a” or “an” limits any particular claim containing suchintroduced claim recitation to embodiments containing only one suchrecitation, even when the same claim includes the introductory phrases“one or more” or “at least one” and indefinite articles such as “a” or“an” (e.g., “a” and/or “an” should typically be interpreted to mean “atleast one” or “one or more”); the same holds true for the use ofdefinite articles used to introduce claim recitations. In addition, evenif a specific number of an introduced claim recitation is explicitlyrecited, those skilled in the art will recognize that such recitationshould typically be interpreted to mean at least the recited number(e.g., the bare recitation of “two recitations,” without othermodifiers, typically means at least two recitations, or two or morerecitations). Furthermore, in those instances where a conventionanalogous to “at least one of A, B, and C, etc.” is used, in generalsuch a construction is intended in the sense one having skill in the artwould understand the convention (e.g., “a system having at least one ofA, B, and C” would include but not be limited to systems that have Aalone, B alone, C alone, A and B together, A and C together, B and Ctogether, and/or A, B, and C together, etc.). In those instances where aconvention analogous to “at least one of A, B, or C, etc.” is used, ingeneral such a construction is intended in the sense one having skill inthe art would understand the convention (e.g., “a system having at leastone of A, B, or C” would include but not be limited to systems that haveA alone, B alone, C alone, A and B together, A and C together, B and Ctogether, and/or A, B, and C together, etc.). It will be furtherunderstood by those within the art that virtually any disjunctive wordand/or phrase presenting two or more alternative terms, whether in thedescription, claims, or drawings, should be understood to contemplatethe possibilities of including one of the terms, either of the terms, orboth terms. For example, the phrase “A or B” will be understood toinclude the possibilities of “A” or “B” or “A and B.”

All numbers expressing quantities of ingredients, reaction conditions,and so forth used in the specification are to be understood as beingmodified in all instances by the term ‘about.’ Accordingly, unlessindicated to the contrary, the numerical parameters set forth herein areapproximations that may vary depending upon the desired propertiessought to be obtained. At the very least, and not as an attempt to limitthe application of the doctrine of equivalents to the scope of anyclaims in any application claiming priority to the present application,each numerical parameter should be construed in light of the number ofsignificant digits and ordinary rounding approaches.

Furthermore, although the foregoing has been described in some detail byway of illustrations and examples for purposes of clarity andunderstanding, it is apparent to those skilled in the art that certainchanges and modifications may be practiced. Therefore, the descriptionand examples should not be construed as limiting the scope of theinvention to the specific embodiments and examples described herein, butrather to also cover all modification and alternatives coming with thetrue scope and spirit of the invention.

What is claimed is:
 1. A method for monitoring a host's glucose levelsmeasured using a continuous glucose monitoring system, comprising:receiving a voice input using a mobile computing device; processing thevoice input to determine one or more commands; and implementing the oneor more commands.
 2. The method of claim 1, wherein the one or morecommands is outputting a particular glucose value.
 3. The method ofclaim 2, wherein the particular glucose value is the current glucosevalue.
 4. The method of claim 1, wherein the voice input comprises anindication of a past time frame and the particular glucose value is aglucose value corresponding to the past time frame.
 5. The method ofclaim 1, wherein the outputting comprises audibly providing theparticular glucose value using the mobile computing device anddisplaying the current glucose value on a display of the mobilecomputing device.
 6. The method of claim 5, wherein outputting furthercomprises triggering display of a glucose trend graph of the host'smeasured glucose concentration over time.
 7. The method of claim 1,wherein the one or more commands is calibrating the glucose monitoringsystem using a calibration value indicated in the voice input.
 8. Themethod of claim 7, further comprising confirming the calibration valuebased on a difference between the calibration value and a currentglucose value associated with the host.
 9. The method of claim 1,wherein the voice input comprises an instruction to modify alertsettings of the continuous glucose monitoring system, and wherein theone or more commands comprise modifying one or more alert settings inaccordance with the instructions.
 10. The method of claim 1, whereinmodifying the alert settings comprises one or more of modifying andalarm profile, changing an alarm threshold, and turning off or on aparticular alarm.
 11. The method of claim 1, wherein the voice inputcomprises an acknowledgement of an alert previously triggered by theremote monitoring system, and wherein the one or more commands compriseturning off the triggered alert.
 12. The method of claim 1, wherein thevoice input comprises an indication of one of a plurality of host's auser is remotely monitoring using the glucose monitoring system.
 13. Themethod of claim 12, wherein the one or more commands includes selectingthe host and wherein the outputting comprises audibly providing and/ordisplaying a state of the host.
 14. The method of claim 13, wherein thestate of the host comprises one or more of a current glucose value ofthe host, a rate of change of glucose concentration of the host, and alocation of the host.
 15. A method for monitoring a host's glucoselevels measured using a continuous glucose monitoring system,comprising: enabling a voice feedback setting of the continuous glucosemonitoring system using a mobile computing device; receiving continuousglucose sensor data measured by the continuous glucose monitoringsystem; processing the continuous glucose sensor data; and outputtingvoice feedback using the mobile computing device in accordance with thevoice feedback setting and the processed continuous glucose sensor data.16. The method of claim 15, wherein enabling the voice feedback settingincludes selecting at least one of a plurality of alert parameters. 17.The method of claim 16, wherein the plurality of alert parameterscomprises a time interval for automatically providing voice feedback, aglucose threshold and a rate of change threshold.